We run more than 10,000 jobs on a daily basis and it is always handled effectively.

This is a good product. Since the scalability is automated, we do not have to wait on the alerts and manually increase the size.

The scalability is brilliant. We've got 23 machines. We have redundancy integrated into this environment. 

If a server goes down, we can turn that queue off and re-queue those jobs to another server, while we get a new image spun up and restarted. In that situation, the delay is in getting the IT guys to spin up the image. If we could get an image spun up when it failed, it would be a matter of five or 10 minutes to be back in business with that server. As it is, once the IT guys do spin it up, we kick off from there.

The main interface is used by about 12 people. The dashboard that we've built on top of it is probably used by 70 to 80 people. But the number of people it affects is in the thousands across the entire organization.

It's heavily utilized across a number of departments in the organization and they really do rely on ActiveBatch to stay up and stable and to provide their reporting mechanisms.

I run jobs across two domains, all US time zones, and I have not found an issue where I couldn't run a job across a specific time zone yet. So, I think it's pretty scalable. It does what I am looking for it to do every day, and I have not found an issue where I couldn't do something. I don't have to chase after anybody to help me figure out, "How do I make the software do X, Y, and Z?"

A team of four of us, including myself, configure and monitor the software. I can't tell you how big the IT team is that supports the agents, which is how ActiveBatch runs, but there are a number of folks in that position. As a firm, we are not very big in numbers, but we respond pretty quickly if there is a problem somewhere internally that needs to be looked at and something has to be jumped on.

I find ActiveBatch very user-friendly and responsive. We are a pretty small company, as far as numbers go, and if it couldn't support what we're doing, then I would find another solution.

I do not foresee any challenges with the software scalability, bigger organizations can easily deploy however pricing might be the primary concern for smaller organizations.

It is a very good, scalable solution.

We started with just a few jobs and are right now up to 500 jobs that we run. When adding new things, it allows you to put everything in its own folders, so you can keep track of different parts. You can flag them as part of different systems, if you want. As we have added more things, we have seen no degradation in the performance.

We use it more as an automation tool, so it is just running jobs. In terms of people who go into ActiveBatch to look at it, we have our two daily operators who go in and look how things are running. We do have some jobs that they go in and trigger, because we're still automating the actual execution of these jobs, but they're all still controlled from ActiveBatch. We have a number of programmers, probably about a dozen, who will go into ActiveBatch. Some will tinker around with creating jobs that they need in our test system. Some will go into production to see how their jobs ran, if they're supporting the system. They can go in and see what the end result was, if it came back successful, had a warning, or an error. They can look at the logs to see what the problem was, allowing them to fix the process themselves.

Right now, we don't have any end users going into the system directly. We're building them a web interface front-end where they will be able to trigger specific jobs, so they can see the jobs that they can control. We have it setup through the ActiveBatch API so it returns the results to that web interface of how the job ran the previous time and when it ran last.

Our nightly cycle is 99.5 percent automated right now. We're finishing up the last few pieces of that. We have started looking at all of our daytime operator jobs. Those are being worked on next. All of our reports sent out to users on a daily basis are all automated within ActiveBatch to be triggered at specific times and sent out. The next piece that we will be working on is giving our programmers the ability to bring up Azure sites as needed, then we will be starting to add in all of our FTP jobs into ActiveBatch as well.

The scalability is great. We are onboarding new users, and our number of jobs is growing. We have not faced any problems.

Right now, we have four execution agents, and they are sitting pretty idle for the most part. If we find that we're starting to see taxed resources on our execution agents, then we have the capability of spinning up more. So, we can run hundreds of servers and automation, if we wanted to.

There are only three of us who have been working with ActiveBatch, which is a good fit. We have one admin who is a developer first, then admin second. Then, there are two of us, who are server people first and developers second. All three of us manage all the different job libraries out there.

In the entire organization, there are about 1,300 of us using the different processes. A lot of people who would be more hands-on are the IT department, mainly because we are directly involved with all the different console apps. We have actually got a significant number of console apps, just because SCORCH couldn't do some of the things that ActiveBatch can do, so our developer teams went in and created the console app. At this point, all that ActiveBatch really needed to do was to be able to run an executable and provide an exit code on it, then let us know if it fails. There are some other business units who are involved a bit more along the way due to the movement of money, for example.

It is heavily used, at least in terms of what is out there. There is a lot of interest in adoption of using it in the future along with a lot of processes that people are really pushing to get put into ActiveBatch. They still have the mentality that a lot of it needs to be done as a console app. However, with us just ending the migration phase of things, we are trying to just get everything moved over so we can shut down the servers. Then, the next step in the future, probably 2021, we'll end up focusing on what ActiveBatch can do without us having to write a console app. 75 percent of the time, we could have ActiveBatch do it natively. There is just a matter of getting a lot of the IT developers to feel comfortable with adopting it as a platform.

We are not the biggest shop out there. In our production environment, there are about 10 group who are doing work on a daily basis. Our user base is primarily developers and a few technical business analysts. There are approximately 50 to 100 users.

We have administrators, operations people, and developers. Administrators have full control across all environments. Operators have the ability to execute and see things across many of the environments. Developers can only work on a nonproduction event. 

For what we are doing on a relatively modest machine, ActiveBatch hasn't had any issues.

I haven't had to scale it yet. It has been a simple server for 13 to 14 years now. I haven't had to go to multicluster. We have a failover setup. However, we don't use that for parallel processing. It is more just for failing. 

I'd rate the scalability nine out of ten.

In terms of bandwidth, we've not had an issue. There are no limitations that I can see.

I'd rate the scalability eight out of ten.

Organizations with more than 1000-1500 employees can scale easily.

I know it has features for scaling, so as we continue to build it out as an enterprise tool we're able to use what they call a Virtual Root. The team using it doesn't see everybody else's work, they only see what's relevant to them. That's really neat. 

We went from one team using it to some four or five teams using it now. The other teams are just starting, but I don't see any collisions. It's easy to grow.

We have about 30 users of the solution, including developers, solution architects, operations, trainers, administrators, and data modelers.

The scalability is quite good. You can add more agents. We haven't had any performance problems or issues with it.

The number of jobs and the number of applications that take advantage of ActiveBatch are growing constantly within our company. 

ActiveBatch Workload Automation is a scalable solution.

The scalability of the solution is good.

It seems very scalable. We use a very small portion of the functionality and the available types of jobs. Of the job steps in the library, we only use about 2 or 3 percent of them. We bought it for a specific purpose and it served our purpose quite well.

The scalability it provides is fabulous and reliable.

The overall scalability provided by ActiveBatch is great.

There are no scalability issues. It easily can be used in a company with more than 1,000 employees.

Our company is small, with perhaps seven or eight people using ActiveBatch. We have hundreds of jobs running and we haven't had any problems. The scheduler continues to do its job.

We have limited users in this product. We have a couple of developers (EDI specialists) who look at some of this stuff. We probably have several hundred people who end up with the end result (report distribution) of ActiveBatch via email. We distribute mainly via phones.

The solution is scalable. We had around 50 people in the company using ActiveBatch as a tool. It was embedded more into the business side so it was used by the finance department, and the risk department, and it was used in customer marketing.

We've never run into any bandwidth issues, but we're also a pretty small company. The number of jobs that we run is much smaller than a larger company would run. We've talked with other companies that use ActiveBatch and they have far more jobs running concurrently than we do. They have never expressed any issue with bandwidth either. 

From my experience, it seems like it's very scalable. You can create jobs in a manner that they can be reused for multiple clients, using variables. We've never had any issue with the number of concurrent jobs running.

ActiveBatch is running around 300 jobs for us. As our company grows, we'll use it more and more. It's integral to our processing that we have built our business around. As we get more and more clients, we will be using and creating more and more jobs. Eventually, we'll probably need to add additional resources to help with that. It's as scalable as our company is.