Tidal by Redwood Reviews

For most of the companies where I have put Tidal in, it runs everything. It does back office, handles trading, reporting of time, doing a lot of file transfers between vendors and regulatory bodies, etc. We use it to do a whole variety of things.

File transfers are our most valuable use cases because those are the ones where we tend to have service level agreements and potential fines.

Right now, we are just in a traditional installation with local servers.

We use the solution from Hadoop and Workday and are not using adapters from them.

It saves times due to automation. With some files, we do hundreds a day for a particular vendor. This would be hard to do manually. Also, the speed at which we can do this is excellent. We do all types of stuff, like we print checks for customers at the local office, which used to take a bunch of time, but now, we can do it in a minute or two.

Windows and Linux are our servers. We use it there, then we do things between Workday or the business application for Oracle. We can do processes which include local scripts or work with these different tools, then they can blend them altogether with Tidal. It does a very good job of managing cross-platform, cross-application workloads. It lets our command center monitor a bunch of things from one screen.

The solution enables admins and users to see information relevant to them. We do a lot of this as we have different teams who want to monitor their own jobs or be involved with their own support. They can do that. With the different levels of security within the tool, we can allow people to rerun jobs or just view information and different things based on their need and security requirements. This helps us decentralize a lot activity. If users can look at things themselves, or potentially certain groups can rerun jobs, we can offload that from the command center or other support teams.

We need to have less Tidal specific support people and more generalists, as they know their own applications in more depth than any of us. It lets them more effectively do their support, and not need to have other people do support, like in the command center or Tidal team. The solution has increased productivity by getting people's problems resolved faster. It also helps those teams understand how things work a little better, so maybe they can improve their processes.

If we can get the problem solving closest to the people who know the resources, we don't have to bring in the Tidal team since a lot of this stuff is not an actual Tidal problem. It's more a problem with their script or server, etc. Therefore, they can get work on their specific issue themselves. For example, we can't fix their script or if there's a problem with their server. That's not our team's function. They can get to that faster. Or, the people who are monitoring, like the command center, can help get their ticket to the right group faster.

Until recently, I had to be available on call. Now, that has greatly dropped. We have these different groups who take more responsibility for themselves. Before, if anything went wrong, they called Tidal, who would say, "Your script is not our problem." Now, they're able to route those tickets more effectively, and those of us who are on the Tidal team don't have a standard on call anymore.

Customers, in general, tell me that all the built-in alerting capabilities are valuable. If you want to send an email, Tidal knows how to do that, where with other tools you have to write a script. If you want to send an email or do an alert that a job failed, that is all built-in and can interact with industry standard tools to help automate the command center process.

The solution is very good in terms of user-friendliness, as it's web-based. We can use it with a number of different browsers, so it gives us a lot of flexibility.

Our admins use the solution’s drill-down functionality all the time to investigate data or processes. They use Tidal constantly to help debug their own processes without necessarily involving a Tidal person. This is just for everyday operations where we are getting file transfers or something that doesn't work, then the admins can look at the output. They can follow the stream and dependencies. E.g., maybe the upstream job didn't create the file. There are variety of things that they can do themselves.

People seem to pick it up pretty quickly because it is similar to a lot of things that they are used to in Windows with the same sort of structure. We don't give a lot of training, so they generally learn by doing pretty quickly. Creating a basic job is very straightforward. A person can create a basic job in a few hours. It is just learning some of the more nuances about how to use different dependencies and rerunning strategies that they will need to learn over time. 

The new reporting tool, Tidal Explorer, will help a lot of people with tools for looking at their overall design. It is able to drill down and get all types of statistics. It's just a really powerful tool, which has some basic searching functions to find where a variable used, etc. This is the sort of thing that a lot of everyday users are trying to find. E.g., if you don't know how something's used, you can go and search for directory to find all the jobs using that directory. Therefore, it is a really useful tool.

I would like more involvement with the cloud. That is something I know we were interested in, as we are moving applications. One client's management team has told Tidal that they would like to see integration with the new application.

They have been doing a pretty good job on improving it. The update of the client to not have a separate database has been a big improvement because that could add another bottleneck. Right now, it's a much faster process, where it has an in-memory database instead of having to go to a database until you read all this stuff.

About 20 years.

The basics have always been strong. What is useful for most people, the addition of cloud support and different applications which can use adapters. That comes into play. The ability to interface with Internet functions makes it a pretty strong tool.

Deployment and maintenance depends on the size of the organization. One or two people are probably need, but it can even be a part-time function. The roles of these people also depend. Companies can set up administrator type work, which is to set up the environment, providing the care and feeding of it, such as adding new agents or new users. They are just overseeing the day-to-day maintenance and running of it. There is not much activity with that. Then, there is creating jobs, which is sort of the application side. This is usually the monitoring side where somebody is watching the actual status of jobs and responding to failures or other alerts.

The scalability has been very strong. We haven't been able to hit any limits. I feel like with this technology the speed of systems and networks increases, and what might've been a problem 10 years ago, is not a problem now.

The role of the end user depends on the team, but some of them can create their own jobs. In other cases, they will give us the specifics and another team will create the jobs for them. So, it depends on how involved your team wants to be. We'll give anybody read access, so they can see the output of their jobs, for example. But other teams, who have a little more knowledge, might give more access where they could rerun or create their own jobs.

I don't know about specific plans to increase it other than bringing in those cron jobs which are not using it.

The technical support is very good. They are very responsive when we have an issue. The last issue that I worked on was that we had an issue with the Transporter and they got a patch for that.

Their initial response is very quick, less than an hour. Then, depending on how long it takes to work with development, it may take a bit more time to get a patch, about a week. This is for non-emergency cases. For something that is a higher priority, they can get things faster.

Tidal, the organization, has been really easy to work with. They are interested in making the tool and use of it as easy for customers as possible. For example, recently they have added onto the support site and there are all types of video training that you can take which are included in your support. Even if you are a fairly large company, you do training. I would typically be brought in to do training when people are first using the tool. But they don't keep doing the training over time, as they expect people to learn it from the other guys. Having this availability so you can look at a video based on your time, and it's free, helps you to look at some features you don't normally use, use some other ideas, and help you pick up skills that you don't necessarily have time to do sitting down with somebody. You can watch these videos as you need them.

I have worked with other workload automation solutions before, but nothing that is still around. 

Even though we have been a Tidal user for quite awhile, there was still stuff being run with Windows Scheduler or cron. We have been able to pull that stuff in and reduce the workload on teams.

Having done the setup many for different customers, it is pretty straightforward. In most places, if they took the time to look at the documentation, they could do a lot of the installation themselves.

A traditional deployment takes half a day or less. You get the basic Tidal setup going, then you have to start getting your agents. That's going to depend on how many servers you have. However, setting up the basic and backup master, fault monitor, and client manager can typically be done in half a day.

The documentation is pretty straightforward. You first want to install the master and client manager to sort of test your basic configuration. Then, you add on the fault tolerant parts of the operation.

Overall, the TCO is pretty good. There has never really been a conversation where any customers I have worked with complained about it.

The pricing is pretty reasonable. That seems to help a lot versus other companies. There are no other fees aside from the standard licensing fees. There are other products out there where you pay based on how many jobs you run and so on, and I know that's very frustrating for users.

The solution’s licensing model in terms of its flexibility and transparency regarding costs is pretty good. A person can buy the license, and if you decide to stop support, you can do that but still have the product. So, it's not like you're paying constantly to keep that license alive. Certainly, you want to keep support going too. Once you buy it, you own it. It's not like I have to keep paying somebody to keep using it.

If you are willing to shop around to other vendors, you can possibly get a good price on your support license.

The customer's ability to budget for the solution, given that there are no costs for upgrades and other enhancements, is a very positive factor. I have signed on people who have left Control-M because they could not budget accurately because based on how many jobs you run, you are writing a check every month.

I've heard good things about Control-M, but their biggest problem is their pricing. You get everything, so it's expensive to begin with, then you keep paying for your usage. Technically, I hear it's a nice product, but it's more the pricing that drives people away.

I used to work for Tidal and Cisco, supporting Tidal. I'm not an everyday user. I haven't worked for the current Tidal people, but I worked for the original Tidal. When I started back with the original Tidal, Cisco didn't put as much money into it as maybe we could've used. So, it sort of stagnated in some people's view. Now, the new people are putting a lot of money and effort into it.

In some ways, Tidal has kept me from having to learn more about different operating systems or tools because I can automate stuff. I don't have to necessarily know all the internals of different things. It has expanded the areas that I can work in without necessarily having a lot of training in different things. E.g., I don't need to be a Informatica expert to be able to run Informatica jobs.

You now have the ability to start something from the cloud, and that is the most powerful way to go forward. Because there is cloud support, if I was going to be starting new, I would look into doing a cloud implementation right from the beginning. E.g., one of my customers did a major data center move, and we had to rebuild all their servers and duplicate all their software. If that had been in cloud, it would've been just been a drag and drop type of a thing. You wouldn't even know what building you were in.

I would rate it an eight (out of 10). There is room for improvement, but the solution is pretty good. The support has always been very good.

We primarily use it for scheduling our JD Edwards ERP software batch jobs.

The solution runs on Windows. It also integrates with our Unix & AIX systems. We use it for automating EDI transactions, so it reaches out to FTP sites as well.

The solution’s drill-down functionality is really good. It can be limited to just seeing a specific job or a group of jobs, depending upon the person's location.

We utilize Tidal for updating other computer systems used within the plants with JD Edwards transactions. This functionality alone saves a lot of time so personnel didn't have to manually run jobs to update the other systems. 

The ease of scheduling is its most valuable feature, and how easy it is to actually schedule something. One of the best things is the calendars and how flexible the calendars can be. Or, you can create your own calendar to match whatever schedule you want or need the job to be run. That is huge for us.

We use the solution for cross-platform, cross-application workloads. The solution’s ability to manage and monitor these workloads is very easy and accurate. We use the job dependencies feature A LOT... meaning one job doesn't start until the last one finished successfully and so on. Another fabulous feature is the file dependencies. A particular job does not start running until a file exists in the location specified but that file is on a completely different server. So, it is cross systems.

It's pretty easy to understand and learn. I did not go through any training for it, we have a test environment so I 'played' a lot there and learned the capabilities of this powerful scheduler. Some guidance as to how the solution is setup and configured today is needed, so users stay within those boundaries. It takes less than half a day (four hours) to onboard new administrators.

I know they are working on improving this already, but there needs to be better reporting. Currently, there are only like three or five reports that we can get off of the system. They already have a solution to this in the new version. I.e., a schedule of all the jobs running for one day, specifically calling out what dependencies that a job relies on. It would be like a flow chart of how the day's jobs would run.

Over 14 years.

The stability is excellent. There are days we don't even log into the product because it just continues to run seamlessly.

We don't have it open to our users and don't actually see a need to do that at this point.

The system administrator is the regular user of the solution. They do the maintenance of the solution, if needed.

We have jobs that run every 2 minutes all throughout the day as well as hourly jobs that run.

Luckily, I haven't had a need to use the technical support.

Except for one time, when Java got accidentally upgraded, and it slowed our performance terribly but they were absolutely amazing and great to work with!

In my past job, I have used HelpSystems Robot. At the time, HelpSystems only ran on an AS/400 or iSeries while the Tidal solution runs on various platforms. They are pretty comparable though for functionality.

It was already at the company when I got here.

We upgraded earlier this year, but we used a business partner (Blue House) because I did not know how to do it.  Since I watched them, I could probably do it myself going forward, as the process was fairly straight forward. We were done within just a couple of hours.

Blue House was great to work with and the process itself was easy. 

We have seen ROI from savings in time. We run on average about 2,200 jobs a day. This is a cost savings for us due to the fact that our users do not have to run these jobs manually since Tidal will do it for them.  As an estimate, this has probably freed up 10 full-time people, in the various departments, about an hour or two a day.

We pay maintenance annually through BlueHouse of about $9,000. That i's for our two environments: production and test and some adapters to integrate with other systems.

My company did evaluate other solutions. They chose Tidal because it was one of two solutions which ran on the hardware that they had at the time, an AIX platform.

It's a great product. I endorse it because it is stable, and that is a big thing for us!

Give it a shot. Get a trial. Test it out. You'll come up with probably the same thing that we did and purchase the product.

I would give it a nine (out of 10). There is a little room for improvement, but overall the solution is exactly what we need and rely on.

This solution does enable admins and users to see the information relevant to them, but we do not have that enabled for our users.

Because we run 24/7/365 and are open all the time, the solution has not really reduced weekend hours for us.

For us, the calendaring system is very robust. Some of the teams have very specific requests for when they need jobs to run. That's been really valuable, because a lot of times, when people run scripts, if they run on a holiday, they're going to fail. We've even started adding some European holidays and other times when scripts should not run because they're going to fail, because they try to connect to external exchanges that are closed on a holiday. For things like that, things you can't do in a lot of built-in scheduling tools, Tidal has been very helpful. A couple of times a month it probably saves us work and the necessity of logging in from home and checking to make sure everything's okay.

Especially in the newer versions of Tidal, the segmentation of user permissions enables us to give people operator permissions for their jobs, to rerun jobs, but view-only for other groups' jobs. We're able to keep people from hurting themselves or other groups accidentally. The permissioning is really good. We have 20 different root-level job groups that hold all of the jobs for each team underneath it, in our shared space. I can set it so that the database group only sees database jobs, if that's all they want to see, so it's not cluttered with everyone else's jobs. But if there are teams that need to see all the spaces, we can do that as well. We can let them see only certain servers or certain users to run jobs. You can edit it too so that people don't see too much or don't get confused and lost in this sea of the thousands of jobs that they could be seeing, when they only need to see their own. That's been nice to set up over time.

In the past year, in particular, the client has gotten tremendously better. If you asked me three years ago, I would have said that the client was the biggest problem with Tidal. The backend was always really solid, but the client was pretty bad for a while. In the past year, with the new company taking over and putting a lot of development effort into the clients, especially the web client, it has really made people a lot happier when having to use the client and work with it. In the past, they begrudgingly used the client, but now they're happy to use it, which is a big change.

Because we've been with Tidal for so long, I can't compare it to the way things were before Tidal. Back before Tidal, there was much less electronic trading.

But an example of how we benefit from it is that we have Tidal jobs that load all of the trading symbols into our database every morning before trading opens. That's mission-critical in terms of getting ready for the traders to start trading on a specific day. If they don't have that updated information through the database, they can't trade.

There's a lot of overnight, big-data processing that happens, things that need to run all night. That's launched through Tidal and monitored as well. It's pretty much a 24/7 operation in terms of uptime, and we've definitely used Tidal to meet that goal.

The solution has increased productivity by saving staff hours. We have an operations team that's here 24/7. We have a runbook that says, "Okay, if this job fails, do this." I'd say 80 to 90 percent of the time the operations team is able to resolve a problem by following runbook and steps without having to contact someone overnight or on the weekends. But Tidal does save the person who owns the Tidal job from having to do work in off-hours especially.

What I like about the new company is that if you ask for something, and they feel like it would be a valid improvement, they're willing to push it out, even if it's a few months out. They make sure to provide it at some point. It doesn't just get lost in the mix.

I work for a financial trading company: stocks and options. The use cases depend on each group that is using it. We have a compliance group, HR group, and a bunch of trading groups and technologists. It's used for a thousand different things depending on the group. It's all to support a financial trading firm, and the processes that happen before the market opens and after the market.

We have a pretty good mix of Linux and Windows boxes, a good 60 percent Linux and 40 percent Windows. We launch trading scripts to start processes up, to stop processes, and to pull in data from third-party vendors; we have FTP jobs that do that. We run an Oracle backend.

From talking to the Tidal people, we have a lot of agents connected to masters, compared to most other firms. But we're probably middle-of-the-road in terms of how many jobs run per day. We're only slightly over 100,000 jobs per day, throughout the whole space.

The biggest problem for us was the Transporter tool that works through the API. It's like a GUI into the API where you can transfer and compare jobs between two Tidal spaces. Up until the last few months, the Transporter tool that was offered was not really good at all. It was hard to take a job in development and promote it to production. There was no really good tool to do that. They offered a tool, but it wasn't that good.

But they just put out the Tidal Explorer tool, which is basically a replacement for the Transporter. That looks promising. I haven't really gotten to use it yet, but it seems to be a better system. That's what people have been requesting for a while now: an easy way to promote and review changes; something like a script repository-type of system, where you can promote something or pull it down, compare it, and then, if you like it, push it. If it doesn't work, you can back it out to previous revisions. It looks like it offers all those features, but I really haven't had a chance to dig into it. I set it up and it does look promising for the future. It's probably something that we're going to try to integrate into the day-to-day processing once it gets released. I don't think it has even been released as general-availability yet. It's still in beta. But once it gets to be production-ready, we would definitely love to use it. It's something that's been on our radar for a while now.

Tidal also had a cache database, which was a copy of the master database, that the web client used. They got rid of that in the latest version, and that is something we had been asking for, for a long time. The way it had been set up didn't really seem optimal.

It looks like they're trying to put forth a better tool for certain places that were lacking.

On another topic, we have to set up ways to send a job event that finds a job that completes abnormally. What we do is send it to an SNMP trap that gets aggregated into one space and we can see those errors. We try not to use Tidal for monitoring, as much as for job launching and tracking. We have a Nagios setup so that if something fails, the error can be sent to Nagios and checked there. If a job is a long-running job, like an eight-hour job, we don't want that job active in Tidal for the whole time and taking up a job slot. We'll kick the job off in Tidal and it will show that it has completed normally. Then we'll hand it off to another tool to monitor that the process is running for the specified amount of time. I don't know if Tidal wants to get into the business of monitoring long-running jobs, but that could be a feature for the future: a job launching and monitoring tool. Using Tidal for monitoring doesn't seem like a good fit, but if they could offer something that did that as an add-on or include it, it might be helpful.

Finally, the solution is a little tough to learn. Talking to people who are new to using the Tidal interface, it's difficult. But I don't have anything to compare that to. They have said it's not as difficult as Control-M or some of the larger scheduling systems that people have used. It's not as hard as that. Tidal has worked to prevent new users, especially, who aren't exactly sure what they're doing, from hurting themselves too much, which is good. They've put a lot of restrictions in place to prevent people from doing things that weren't intended. There is a learning curve, but I don't think it's steeper than any other new scheduling system. In the past, we've downloaded some other options and they had a learning curve too. If you've never used it, there's always a curve, with the terminology, etc. But I don't think it's any harder than any of the others.

New users of Tidal need at least a month of working with it a little bit each day. I give people a three-hour introductory course. Every quarter I provide an overview for new users of how things are set up. Luckily, in our company, a lot of these new users are joining groups that already use Tidal on a daily basis. If they have any questions after the initial course, they can talk to their team. Over time, the teams that use Tidal are resources for the new employees. That takes a little bit of training off of my plate. Within a few months people are confident and moving along. It takes a few hours to pick up but to be fully confident it would take a few months to really feel that you know what you're doing in the space.

We've been using Tidal Workload Automation for 15 years.

I'm really confident in the stability.

Cisco owned the company for a few years and I felt that it was something of an afterthought for them; it wasn't really their business. They didn't really put the time and effort into it. It seemed like, for a couple of years, nothing was getting resolved and people were pretty unhappy. We ended up staying in a version that was years and years old, compared to what we should have been on because we were not confident in the solution that they were providing, to give us what we needed. 

In the past two or three years, since the new company took over, we have much more confidence. People are much happier with the direction that Tidal is going and the features that they're releasing.

Our usage of Tidal goes up every year. That's not even from planning to increase usage. We have a few holdouts, people who still use Task Scheduler or cron, but over time they've all been folding into the Tidal space to have a better overview and a cross-platform way to see everything and rerun everything and be alerted. They've come to the conclusion that it's a better method, especially for overnight. We have an operations team that manages things overnight, so that if something fails in the middle of the night, that team can handle it, which they would not be able to do if it wasn't in Tidal, along with thousands of other jobs.

In terms of the number of jobs in Tidal, it's been increasing at between 10 and 20 percent a year. It's going up. It's definitely not going down. Initially, it was probably 50 percent a year because everyone was adopting it. Over the past five years, since it was already utilized by everyone, there has been a general 10 percent a year increase because of new jobs that need to be created and new processes that need to be started and stopped.

We're somewhere around 95 percent in terms of adoption of Tidal. There a few small groups that like to do their own thing and use open-source products, but those are groups that maybe only run Unix and that's it. They're happy with Jenkins or something open-source that only needs to run a few hundred jobs. It's only one platform, and it does what they need to do a little bit better than Tidal. But for groups that need an all-in-one solution, they've all gone to Tidal. If they need to do what Tidal offers, they're going through Tidal to do so. It's pretty accepted here.

Tidal was here when I got here. It's been around for a while. But over the past 15 years, I've been the one who researches the new patches and service packs and revisions and I've done all the upgrades.

The upgrading process is straightforward for me, but I've been here so long that it's just something I know. It has gotten much better with the new company. We're on a Unix backend, so a lot of times, with a simple hotfix or service pack, you can just run a shell script and it replaces all the files. It does everything it needs to do. It places everything in the right location, and then all you have to do is start and stop the backend process and it picks up the new revision. That's been really good. In the past, it was a more manual process. In the past couple of years it's gotten much easier in terms of being able to do things with one script.

The releases have been good with very few bugs or installation problems. There were some in the past, a few years ago, where you would try to run something and it wouldn't take into account your environment and it would fail. You'd have to tweak some of the script. That was a lot of manual work. The upgrade scripts, recently, have worked pretty seamlessly.

We have an enterprise contract, so if we want to add another agent, or if we want to add another master, we don't have any restrictions on those things. Other vendors don't have that flexibility. For me, as an admin, that makes it easy because I don't have to think about what a new master is going to cost or what a new agent is going to cost. If someone needs a new agent and they need to run a job from that agent, we just go ahead and do it. If we're in Dublin, Ireland and someone wants a new master because there's a group over there that wants to adopt Tidal, we can just say, "Sure, get a new license, create, and you're fine." For the license that we have, the flexibility is great.

I don't know if other people aren't happy with the licensing model because they have a non-enterprise license where they have to think about everything they change.

We're negotiating our new license now for April, which is when we have to renew. We've usually gone with a three-year license. The numbers that the new company has put forward haven't really changed significantly from our past renewal. People here are pretty happy with that. It's not like the new company came on and jacked the prices up exponentially. The new prices that we've received seem reasonable and comparable to the marketplace.

Because our environment is older, it's a little tough to integrate some of the newer features that they're offering. That's because of the way we had to configure our environment for older versions that didn't have these newer features. In terms of how you delegate permissions, how you set up calendars, who you give permissions to, my advice would be to figure out how the permissioning structure works before you set up your environment, and stick with a standard. A lot of the time, we're having to go backwards to make things standardized. If we started over right now, I know how I would set up a Tidal environment. It's hard to do that after the fact, and after things have been set up differently in the past. So try to develop the best system for standards and then keep that.

We don't use any of the Tidal adapters that they offer, just because we're heavy on development here. A lot of the people here, in the past, felt that they could write their own wrapper scripts to do the same thing that the adapter jobs do. That's ingrained in our environment now. We don't even look at the adapters too often, just because we have an in-house solution to those.

The vendor is starting to offer tools such as Tidal Repository, but that's going to be an add-on cost. I'm still evaluating whether it's something that we want to try to get a price on and use. It would allow us to see if certain jobs are running longer than they usually run. We could also see if queue levels are hitting their limits often and what we could do about that. The Repository seems like it's going to be a tool to gives you the drill-down information, like seeing how calendars are configured and a lot of the information that you're trying to get at. It's more like an admin dashboard where you can drill down. Right now, I just go directly to the master to search the logs, or we have all the master logs sent to a repository. I can search them there. We're doing things from our side with other monitoring tools we have and log aggregation tools.

We primarily use Tidal Automation to schedule batch jobs. 

We are a solution provider and the automation that we implement is for our clients.

Using this solution has improved the way our organization functions because support is available whenever we have problems.

The most valuable feature is the job scheduler, where you can schedule thousands of jobs to execute at specific times. It will schedule dependencies as well.

There are several improvement points that our team has provided to the vendor. 

Our client has been running Tidal Automation for more than three years. We started taking care of it for them between two and three years ago.

This is a stable tool and we use it extensively.

We have thousands of jobs that are scheduled in a batch and run using this tool. It is scalable, and there are a few hundred users.

Our usage may increase to some extent but maybe not because there are competing forces.

Our team is in touch with the product team and whenever there is any problem, we reach out to support and they take care of the issues.

As we are working for a client, we have an arrangement such that we can raise tickets with the vendor. Once we do so, the problems are addressed.

Overall, the support is good.

We did not use another similar solution prior to Tidal.

The initial setup was completed by our client's team.

We do not maintain the system, aside from the case where an upgrade is needed.

It does generate ROI but I do not have specific metrics available because it is known by my customer. When a customer continues to use the same product for a number of years then it seems that they are happy with the return on investment.

I would rate this solution a seven out of ten.

Tidal Automation by Redwood is a user-friendly solution.

I have been using Tidal Automation by Redwood for one and a half months.

I rate Tidal Automation by Redwood a nine out of ten for stability.

Around eight users are using the solution in our organization.

I rate Tidal Automation by Redwood a nine out of ten for scalability.

The solution’s initial setup is easy.

The solution’s deployment took ten days.

I would recommend Tidal Automation by Redwood as the first priority for users looking for any automation tool.

Overall, I rate Tidal Automation by Redwood a nine out of ten.