3C Release Manager for Automic Enablement Series: Add Related

Previously in this series

This article continues the 3C Release Manager for Automic Enablement Series. If you missed the earlier parts, here is where to catch up:

• Part 1 — Snapshot Function: capturing the full state of an Automic client as a timestamped baseline.
• Part 2 — Diff Function: comparing snapshots to detect object changes and verify release transparency.
• Part 3 — Creating Environments: defining the technical connections to Automic clients that make snapshots, diffs, and deployments possible.
• Part 4 — Controlled Deployments: transporting objects between clients with automatic backups and a defined rollback path.

With controlled deployments in place, the next question is almost always the same: how do you handle deployments when the objects are not neatly grouped in one folder? That is exactly what the 3C Release Manager solves with its related-object collection.

Why nested workflows break traditional transports

Enterprise Automic landscapes are rarely organized around a single, self-contained project. A master workflow — call it Project X — typically references sub-workflows that live in Project Y, Project Z, or shared utility folders. Those sub-workflows in turn call their own tasks, scripts, and includes. The result is a dependency tree that looks clean on paper and gets messy the moment someone has to transport it.

Traditional, folder-based transports fall apart here. Selecting the folder that contains Project X captures only part of the picture. Everything referenced from outside that folder has to be hunted down manually, object by object. One missed include and the deployment fails in the target client — often in a way that only shows up at runtime, not at transport time.

This is not a theoretical edge case. It is the default state of mature Automic environments, and it is one of the most common reasons teams avoid transports until they absolutely have to do them. The 3C Release Manager removes the manual hunting from the equation entirely.

How the 3C Release Manager collects related objects

The deployment workflow starts the same way as any other deployment in the 3C Release Manager for Automic: a new deployment is created, the target client is specified (in the reference scenario, client 101), and the selection is based on a fresh snapshot of the source client. The difference is what happens when objects are added to the deployment package.

Instead of the standard Add action, the 3C Release Manager offers two more powerful options: Add Related and Add Related Recursive. Both start from a master object — in this example, the Project X job plan — and collect dependencies automatically.

Add vs. Add Related vs. Add Related Recursive

The three options cover three very different scopes, and understanding the difference is the key to using them well:

• Add: Adds only the selected object itself. Nothing else. Useful when you know exactly what you want and the object has no dependencies you care about.
• Add Related: Starts from the selected master object and automatically collects all directly related workflows — including sub-workflows from other projects or folders. No more hunting across Project Y and Project Z.
• Add Related Recursive: Goes one critical step further. It collects not only the related sub-workflows, but also the tasks inside those sub-workflows, the scripts those tasks reference, and the includes those scripts depend on. The traversal goes all the way down to script level.

For a complex, nested workflow structure, Add Related Recursive is usually the right answer. It guarantees that the deployment package is complete — every dependency the master workflow needs to run in the target client is collected in a single action.

What this actually changes in practice

The practical impact of recursive related-object collection in the 3C Release Manager goes beyond convenience. It changes four things that matter for anyone running real Automic workloads:

• Completeness by default: Deployments stop failing because of forgotten includes or missed sub-workflows. The dependency tree is resolved once, automatically, and in full.
• Speed: What used to be thirty minutes of manual searching across projects becomes a single click. Deployment preparation time shrinks dramatically.
• Consistency: Two different engineers preparing the same deployment produce the same package. The scope is defined by the object graph, not by human memory.
• Confidence in nested releases: Teams stop avoiding complex deployments because they know the tooling will find everything that needs to come along.

Key takeaways

• Nested, cross-project workflows are the norm in mature Automic landscapes — and they are exactly where folder-based transports break down.
• The 3C Release Manager offers three collection modes: Add, Add Related, and Add Related Recursive, each with a clearly defined scope.
• Add Related Recursive resolves the full dependency tree from a master workflow down to the script and include level in a single action.
• The result is complete, consistent deployment packages prepared in a fraction of the time manual selection would take.
• For real-world enterprise Automic environments, this is the difference between dreading complex transports and treating them as routine.

Mastering related-object deployments is one of the capabilities that turns the 3C Release Manager from a useful tool into a core part of a reliable Automic release process. Tricise supports organizations on both sides of that adoption curve: through the 3C Release Manager for Automic itself, and through consulting and enablement services that help teams build the release governance muscle around it.

Want to see the 3C Release Manager handle your own nested workflows? Schedule a free consultation to discuss how it fits your Automic landscape — or explore the full Automic course path at Tricise University to build the release governance skills across your team.