FAQ

No. IDRuns is a complete workload automation product in its own right, and most of what it does has nothing to do with Tidal. Teams run it as their first real scheduler, or to replace cron sprawl, Windows Task Scheduler and homegrown wrapper scripts — job groups, calendars, agents, dependencies, plugin jobs and live operational views, out of the box. Tidal migration is offered as a services engagement for the teams who need it, not a requirement.

Yes. IDRuns is a direct alternative to Tidal Workload Automation — also known as Cisco Tidal, Tidal Enterprise Scheduler (TES), and now TIDAL by Redwood. It covers the workload-automation feature set most teams actually use — job groups, calendars, agents, dependencies, plugins and live monitoring — at a fraction of Tidal's licensing cost and without a multi-day install.

Run IDRuns alongside your existing Tidal environment and migrate job groups across one at a time. IDRuns includes an automated import that is well suited to demos, evaluations and proofs of concept. For a real conversion we recommend our professional services team, who do the heavy lifting with our own migration tooling and review the result with you. Concepts map closely — job groups, calendars, agent lists, dependencies, variables — so little cleanup is needed, and you can cut the Tidal license once the last group is migrated. Professional-services migration is scoped with you as an engagement.

Yes. IDRuns now supports AutoSys JIL file import, so you can bring AutoSys job definitions in automatically. The automated import is great for demos, evaluations and proofs of concept. For a production conversion from AutoSys we recommend professional services, to review mappings, dependencies and calendars with you.

IDRuns Standard starts at $7,500 a year with five agents included, instead of Tidal's per-agent and per-connector enterprise licensing. It runs as one server process with a single web console instead of a Java desktop client plus master, fault monitor and client manager, and reaches a first running job in minutes rather than days. Volume pricing is available on request.

For most Tidal Enterprise Scheduler (TES) deployments, yes. IDRuns provides scheduled, dependency-driven job execution across many machines with calendars, fiscal periods, agent failover, plugin jobs for SQL Server and REST APIs, and operational views for waiting, active and completed work.

IDRuns targets the same enterprise job-scheduling and workload-automation space as BMC Control-M, Broadcom AutoSys, ActiveBatch and Redwood RunMyJobs, with a focus on a small operational footprint and flat pricing. Teams most often move to IDRuns from Tidal, cron sprawl, or Windows Task Scheduler.

A workload automation tool, also called an enterprise job scheduler or batch scheduler, runs jobs across many servers on calendars and dependencies, alerts or reruns when something fails, and gives operations a live view of what is waiting, running and done. IDRuns provides this with job groups, calendars, agents, dependencies, events and alerts, and adds orchestration pipelines for decisions, loops and approvals.

A scheduler decides when jobs run and in what order, using calendars and dependencies. An orchestrator coordinates multi-step pipelines: conditions, loops, approvals, retries and values passed between steps. IDRuns includes both in one console. Orchestrations call your existing jobs, and a scheduled job can start an orchestration, so pipelines sit inside your normal schedule.

IDRuns is designed to be operated by a small team and is priced well below enterprise scheduler licences. Standard starts at $7,500 a year with five agents included and no per-connector fees. Volume agent pricing is available for larger estates; contact us for a quote. A free 30-day non-production evaluation is available.

Orchestrations are pipelines built on top of your existing jobs. Each one is a graph of steps — run a job or job group, run an inline script, call a built-in tool, test a condition, wait, ask for approval, loop over a list, or start another orchestration — with retries, trigger rules, run parameters and values passed from one step to the next. You build them in a visual designer or as YAML, run them on demand or on a cron schedule, and follow each run live. Orchestrations are an Advanced Option and do not change how regular scheduling works.

Yes. An orchestration can be a full build pipeline: a push to GitHub or GitLab starts a run through a signed webhook, a Git checkout step fetches the commit into a per-run workspace on a build agent, build and test steps run there, JUnit test results and artifacts show on the run page, and a deploy step fetches the artifact on another agent. Protected environments limit which branches may deploy, require an approver and carry their own secrets; concurrency groups keep two deploys from overlapping; and each run reports its result back on the commit as a check. A ready-made Build & deploy template sets it up.

Yes. Everything the console does is available through a REST API using revocable API tokens, and inbound webhooks let any system that can make an HTTP request start one job or job group, optionally passing variable values for that run, or start an orchestration - including signed GitHub and GitLab push and pull-request webhooks. Each webhook is limited to one target, rate-limited and audit-logged.