I have used the UC4 Automic tool, however, when I started using ActiveBatch, I noticed a notable improvement in the efficiency of managed file transfers, facilitating the timely movement of files, including those of a more intricate nature, with enhanced ease and effectiveness.

We have been using ActiveBatch since I joined the company. We have had a lot of enhancements here, and everything is progressing very well.

ActiveBatch replaced Windows Scheduler, Chrome jobs that had been running on some servers. There was also another scheduling tool that popped up somewhere but that data was moved into ActiveBatch. The scheduling from Cognos was also moved into ActiveBatch because it was more convenient, and some of the Tableau scheduling was moved into ActiveBatch as well.

I have been involved in automated scheduling software since 1989. I find this to be the easiest product that I have ever used, especially compared to Robot Schedule and CA AutoSys as well as an in-house scheduling software that I had designed and developed at one time.

I did use AWS and ServiceNow, and the switch is due to the fact that this has improved my time management very efficiently.

There was no transition from similar software.

Previously I was using a different solution.

I switched since that solution was slow and also the cost was more.

Previously, we have only used some scheduling through Microsoft Schedulers and SSRS schedulers.

ActiveBatch is the first software of this nature that I have used. 

We did not use a different solution. 

We see ActiveBatch as the Center of Excellence for all things related to automation for our business. It is the best solution that we have had compared to what we were running before, which was Microsoft System Center Orchestrator (SCORCH). We don't want to have a whole bunch of different solutions out there. Being able to have one solution that can do all our automation is the best way to do it.

We switched over because of the intelligence. We were right in the middle of trying to decide whether we were going to upgrade SCORCH to the latest version or if it was time for us to go a different path. As we started going down through the different requirements that we needed SCORCH to do, we decided that it was time for us to go in a different direction. SCORCH had to be taught everything you wanted it to do, whereas there are a lot of processes that ActiveBatch will just go ahead and handle.

The performance is about the same between the two solutions in terms of doing what they are supposed to do. Where we really have the advantage is the fact that we don't have to reinvent the wheel, e.g., triggers within Active Batch are native and can be set up pretty quickly and easily. Whereas with SCORCH, we struggled with trying to get a schedule setup for that trigger or being able to rely on constraints. For example, if a file doesn't exist, then you really can't do anything. In SCORCH, we had to teach it that if you don't see a file, then hold on a second because we have to wait. Where ActiveBatch just says, "Oh, okay. I know how to do that."

In certain cases, ActiveBatch has resulted in an improvement in workflow completion times, because of the error retries. We can take care of them by telling ActiveBatch that if you have a problem, go ahead, try it again, and modify this. If the job runs at two o'clock in the morning and it failed with SCORCH, we always had to go back, figure out what happened, and how to get it run again. It might have been something as stupid as no network connection, because one of our upstream providers had an outage. Whereas, at least with ActiveBatch, we have been able to build in that self-healing or error detection. Once it sees the connection, it can go ahead and just correct the problem. For example, the Internet might go down from 2:00 AM to 2:15 AM, then by 2:30 AM, it's all back up and running. ActiveBatch can go ahead and finish the task. Where with SCORCH, we were finding that it would fail. Then, at seven o'clock in the morning, we got to troubleshoot any issues that might have come up. 

A lot of times, troubleshooting did not take very long, as it depended on the process. If it's something that could be downloaded from the SFTP, then that relied on several other steps that needed to take place. That might have delayed it a bit because we had to walk through five different processes that normally would have been scheduled to run at 3:00 AM versus 2:00 AM. So, if the Internet is out between 2:00 AM and 2:15 AM, ActiveBatch heals that first process before the second one runs at 3:00 AM. Then, we don't have to go through and do any added troubleshooting because step one didn't work, and step two failed because we can't troubleshoot it until we get up and start looking at it that day.

We first implemented this a number of years ago, it took our processes from several hours overnight, and not knowing if those jobs failed until we checked in the morning, to having an ActiveBatch team as an overnight team who watched jobs for us. Though, sometimes they would take an hour or two before they realized something had failed. Now, we have it so that team is responding within minutes. The alerting that texts and emails you has improved our ability to respond in a timely fashion.

We did not use any software before; it was completely manual.

We didn't have a previous solution.

We were looking for a product that could handle a company-wide insurance systems modernization project. This project has been in the making for years. It boiled down to putting new products on our distributed systems, migrating data from the mainframe to those distributed systems, and eventually sun-setting the mainframe. This approach makes more sense since it's simpler to start with new products rather than migration to begin with and this also allowed us a nice starting point with ActiveBatch.

As the organization changes, we tend to use the most efficient software which is available. 

I have used Selenium previously. However, job scheduling, monitoring dashboard, and email alert features were not there. This is the major reason why I switched to ActiveBatch.

Before ActiveBatch, as they created jobs, they used our DataStage tool as the scheduler. That functionality was within the product.

Other than scheduling in Windows, I don't think our company had a previous solution.

We did not previously use a different solution. 

We didn't use a different solution before using ActiveBatch Workload Automation.

Ninety-five percent of the warehouse jobs that we run that were Informatica jobs have been replaced with ActiveBatch. We have a couple of jobs with some specialized logic that we haven't taken the time to figure out how to do in ActiveBatch yet. Of the 200 workflows, we run a day, 190 of them or so run through ActiveBatch.

I switched to this automation tool due to the fact that ActiveBatch had all the features I was looking for. The automation process was smooth and error-free with ActiveBatch. This saved a lot of time and resources and has improved the overall performance.

I switched from a previously used solution to a more modern automation solution like ActiveBatch due to the fact that the features in ActiveBatch were more advanced and it helped me resolve all the issues. 

The previous automation tool could not adapt to the changing requirements. With ActiveBatch, the work has become truly exceptional.

I previously used Selenium, however, it's all bits and pieces, so we had to switch to ActiveBatch automation.

Everything was a manual effort before ActiveBatch.

Our previous solution was AutoMate BPA. 

We switched because we needed stability. We also needed something that was easy to use where we could have certain functionality, like restarting jobs from different points and reusing steps for multiple clients. Those were things we just did not have in the old tool. Having that stability and the ability to see if a job failed and having adequate log information to indicate why it failed are the biggest reasons why we moved over.