Tidal by Redwood Reviews

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.

I have three installs of Tidal: production, qual and dev. I have a portfolio of 12,000 unique job definitions in production, 13,500 definitions in qual, and about 8,000 in dev.

The Tidal adapters I use are for Windows and Linux agents, as well as Informatica, Cognos, and mSQL.

With the portfolio of jobs that we're talking about, it's continuing to grow. There is way more work being added to the system than there is work that is being retired from it. That's just the way the animal works. It's been able to handle, perfectly fine, the complexity of the interrelationships between the processes.

We actually ported off of Maestro. Maestro was the scheduler that we were using, enterprise-wide, and it was very inefficiently used when I got here. When we came up on Tidal, we didn't convert anything. We built all of the definitions that exist in Tidal. So over the 15 years, that portfolio has grown.

As a whole, we're trying to automate as many things as we can to alleviate the manual processes. One of the things that Tidal has helped us with, because it is cross-platform: We had a number of different schedulers in this organization and we've been porting everything that was running out of these other, unrelated schedulers into this scheduler. That has afforded us the ability to set up direct dependencies between processes that couldn't talk to one another before. Over the 15 years, we've definitely gained a lot from that. What had been manual controls have become automated controls, by using this tool to replace a number of schedulers.

The automation aspect of the solution is the most important. I'm able to construct groupings that have dependencies which automatically allow the proper jobs to run in the proper sequence. That's the strongest selling point of any scheduler.

As for the solution's ability to enable admins and users to see the information relevant to them, the security model that I use is fairly simple and straightforward. For developers and other folks, an inquiry-type access is more suitable for the production environment. I've added functionality for people in both the qual and the dev environments, based on their roles. But I haven't restricted anything, meaning that anyone who has an account can see everything. There is a lot of flexibility in the way that things can be configured with Tidal. You could restrict it down to the point of people only seeing those things that are applicable to them specifically. I found that that would be too restrictive, and result in a lot of overhead to manage. So I went with a much simpler model, but the flexibility is there.

There are certain things I can put in play, triggering events based on statuses. For instance, if I have a certain job type where a number of the jobs are going to "waiting on resource" in the middle of the night, I can configure alerts so that I can assess those and then determine if I have to raise the job limits on some of those resources to make sure that we're not having things held up on necessarily. By the same token, if we're having long-running processes, I may want to tailor that down so we don't have so many processes running concurrently. There's some flexibility in that. I haven't had to rely on it a lot, but there are some features there that can be tapped into.

From an administrative point of view, I wouldn't give really high marks to the solution. I actually entertained getting the JAWS application at one point. One of the shortcomings with the scheduler is the reporting capabilities. At least at the time, JAWS was the best that they had for a third-party integration. I think they've got things in the pipeline to help alleviate that gap.

Also, one of the things I'm concerned about is that, with the security we have, there's a hazard that somebody could go in and accidentally delete a master grouping of definitions out of Tidal. Right now, I don't have an easy way to recover from that. It looks like a couple of things that are in the pipeline with Tidal are going to allow for that kind of recovery. There should eventually be a replacement for the Transporter tool. That sounds like it's going to have the capability of doing copies out of Tidal. If I scheduled that once a week, it would give me a copy of definitions out of Tidal. If it turned out that one of the operators, who had the rights, accidentally deleted a grouping of definitions, I would have something that listed definitions that I could go back to and recover.

I've been using Tidal Workload Automation for about 15 years.

The stability has been fine.

In fact, we're going back to using the master and the fault monitor. We had it disabled for some time, but we've gone back to setting it up with the fault monitor and the master, and the backup. There was a problem with it. There was some kind of a fault status that kept getting triggered. The network person who was in charge convinced us to disable the redundancy that we had set up, and we've just recently gone back to it. And it's been working fine.

We haven't hit any roadblocks with volume, but I think we've been sized properly too, behind the scenes, with each upgrade that we've done. It's been scaling fine. That's the bottom line.

There are systems out there that are larger than ours. We try to get to the user conference, here in Boston once a year, to do some comparisons to other organizations and the way they're using the tools. It's an information-sharing session.

Whenever we go for an upgrade, we look for an assessment of whether we need to provide more horsepower or not. If any of the configuration has to change, we watch that carefully with each upgrade. There's a formula that Tidal provides on whether you should have a small, medium, or large installation, based on the number of definitions that you have. They help with calibrating that.

We consider Tidal to be an enterprise scheduling application, so any new process that comes along is first looked at to see if it can be run from Tidal, whether that would involve purchasing another adapter or whatever else would make it work from here. We want it to be an automated function as opposed to being run manually and not integrated with the scheduler.

The technical support is much improved. That's over the course of 15 years. Tidal has gone to great lengths, with the transition to STA, to strengthen its support capabilities and also strengthen the relationships it has with its clients. STA seems very interested in trying to focus on a direction, advertise that direction, and make the current clients comfortable. That, in turn, will help them take on new clients.

As I mentioned, we came off of Maestro. Back in 2004 or 2005, when we were looking at schedulers, Tidal was one of the solutions we demoed. Universally, we all decided that Tidal seemed to be the better candidate.

The setup was pretty flexible. We had to come up with our own ways of deciding how to group things and what our naming convention would be. 

When we first came up on the product, one of the issues that we noted was that the default sort for all of the jobs was alphabetical. That complicates the ability of the operators to visualize the order jobs should run in. To overcome that, we came up with a naming convention that puts a prefix on all of the job names with a number. So when we create our groupings, within a grouping it will list the jobs in the order that they run. Half of Tidal's clients wanted to see things alphabetically listed and half wanted to see them listed numerically, in the order that they run. The vendor wasn't willing to modify the product to give the user a choice of one order or the other.

I don't remember the original installation taking that long. It took us a while to actually build all of the job definitions. That was a lot of work. It was done within about a week. Once the equipment had been spec'ed out we had an onsite install here in the computer facility.

We've had to train a number of new operators and I don't think it's been a terribly big learning curve for them to understand how it works. The developers, in fact, self-trained in their environments and they seem to be able to maneuver fairly well. There are times I have to explain things here and there, some ways of handling things that are more convention. Those are things they have learned over time. But they seem to do all right with it. There isn't that much of a learning curve.

The only people who need to have the training would be the operations staff. I think there was a beginner's and intermediate course that we originally took, when we came up on the product. And then we learned things as we went. 

One of the things that would be beneficial though would be some training that incorporates best practices. You can go through the manual and it will tell you, "This feature does this," and, "these are the parameters that you need to put in," and then the delimiters, but it doesn't necessarily tell you the best use case for certain functionality. I've had a few people mention to me "Oh, you shouldn't do this, and you shouldn't do that." Well, where does it say that in the book? It doesn't. And that's the problem. There's a little difference between an instructional manual that gives you the nuts and bolts of how to do things, and something that's more tailored to best practices, or recommendations of things you should not do. And some of that has to do with the architecture behind the scenes. Users wouldn't necessarily know that unless there was some documentation expressing it.

I don't really have metrics for ROI. It's more of a feeling because we've been able to consolidate from all these separate scheduling products into this one scheduling tool, allowing us to have direct dependencies between things. That's an efficiency in itself, but I don't have any statistics to support the number of hours saved and the number of dollars saved. Overall, it has improved our business model with automation.

My experience was that it was very difficult to figure out the licensing cost on an annual basis. I don't know if they've changed the model, but I remember it would take a month to reconcile if we were being billed the proper amount because it was based on the number of CPUs; if they were test CPUs or production CPUs. I recall, and this was probably five years ago, that it was very difficult to reconcile the annual statement with what we had, and to verify that they were components we were using.

Our ability to budget for the solution is a fairly easy aspect of it. One of the difficulties that I have internally has to do with the specialized adapters. I don't think it's well known within my company that I can't just snap my fingers and get an adapter. There's a cost associated with it and the license key has to be updated after we've made the outright purchase of it. I don't think there's familiarity, within our company, of budgeting for the coming year if it involves these additional Tidal components. That's nothing to do with Tidal. That's just an internal struggle.

There were five solutions we looked at in total. Two were ruled out right away. When we went to do demos with the three of them, the third one couldn't even do the demo, so it came down to Maestro and Title.

One piece of advice I would have is that if you get into a product, try to keep it upgraded. It's to your benefit, support-wise to be, maybe not on the cutting or the bleeding edge, but close to the current version. That's been a pain point for Tidal, to try and get their clients up to speed.

Stay on the latest version because of the functionality. It's not only relevant to just this tool, but to many IT tools. It's just like the next generation of laptops that are coming out; they're coming out more quickly. The same thing is happening with the functionality that is being added to all of these products, including the scheduling application. It's important to go through the pains of staying up to date.

It's been a good product. We could have done a lot worse. This is a heck of a lot easier to use than some of the other schedulers that I've used in the past. But, then again, it's been proven as a solution, as well. Other solutions are all moving targets. Everybody is making changes in their products. At the time that we made the selection of Tidal, it was definitely constructed a lot better. It was easier to use than the other option.

In terms of the number of users in our organization, I honestly wouldn't mind if everybody in the company had an account to log into Tidal with inquiry access. But I think we've got around 300 accounts set up in each instance. They could be used by managers, developers, operators, and all the other IT folks who have accounts.

For deployment and maintenance of Tidal, since we're doing a 24/7 staff, we're talking about eight people, and three or four other people who are going to be part of production control and/or an IT server ops-type of functionality, because you need that level of support as well from time to time. So we have twelve or so people in one capacity or another maintaining Tidal.

I would give Tidal a solid eight out of 10. 

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.