14.3 Solutions Management: Packaging and Deploying Automations with Their Resources
Key Takeaways
Solutions bundle projects with their Orchestrator resources, such as queues, assets, storage buckets, and triggers.
Solutions are designed in Studio Web and deployed from the Orchestrator Solutions page (Deployments, Packages, Projects).
Deployment asks for the package, version, name, location (Shared by default), solution folder name, activation, and runtime (Default Serverless offered).
Statuses are In progress, Successful, Failed (rolled back), and Failed Rollback.
Resources can be linked to existing ones, and Pipelines activities can automate uploading, deploying, and activating solutions.
14.3 Solutions Management: Packaging and Deploying Automations with Their Resources
Core Concept: A solution bundles an automation with the Orchestrator resources it needs, such as processes, queues, assets, storage buckets, and triggers, so the whole set can be deployed to another folder or tenant in one step. The exam description lists Solutions Management under both Orchestrator and resource management.
Why Solutions Exist
Deploying a single package leaves the rest of the setup to someone: create the queue with the right retry settings, add the assets, create the trigger, and give it all the right names. Solutions capture those resources together, which makes promotion from a development tenant to test and production repeatable.
Lifecycle
| Step | Where | What happens |
|---|---|---|
| Design | Studio Web | Build a solution that contains one or more projects and the resources they use |
| Publish | Studio Web | The solution is published as a solution package with a version |
| Deploy | Orchestrator > Solutions | Choose the package and version and deploy it to a location |
| Activate | Orchestrator | Make the deployed resources active, immediately or later |
| Upgrade or uninstall | Orchestrator | Deploy a newer version over the existing deployment, or remove it |
The Solutions page in Orchestrator has tabs for Deployments, Packages, and Projects. Solutions Management is an Automation Cloud capability.
Deploying a Solution Package
The deployment form asks for:
| Field | Meaning |
|---|---|
| Package and Version | Which solution package and version to deploy |
| Deployment name | A name for this deployment |
| Location | The parent folder where the solution folder is created; Shared by default |
| Solution folder name | The folder created for the solution's resources |
| Activate immediately | Whether resources become active right after deployment |
| Set up runtime | The machine template used to run the processes; Default Serverless is offered by default |
Deployment statuses
| Status | Meaning |
|---|---|
| In progress | The deployment is running |
| Successful | All resources were created |
| Failed | Something went wrong and the deployment was rolled back |
| Failed Rollback | The rollback itself failed and needs attention |
Configuration and Existing Resources
A deployment does not have to create everything from scratch:
- Before deploying, review the configuration of the resources, such as asset values and queue settings for the target environment.
- A solution resource can be linked to an existing resource in the target, such as an asset, storage bucket, webhook, or queue that already exists, instead of creating a duplicate.
- Environment-specific values belong in the deployment configuration, not in the workflow.
Permissions
Solution deployments and packages have their own tenant permissions (Solution deployments and Solution packages: View, Edit, Create, Delete), which the Orchestrator Administrator role includes. Orchestrator also has the default roles Solutions Administrator and Solutions Contributor for teams that manage solutions without full administration rights.
Solutions Versus Deploying Packages Only
| Aspect | Package only | Solution |
|---|---|---|
| Contains | Workflows and dependencies | Projects plus Orchestrator resources and their configuration |
| Queues, assets, buckets, triggers | Created manually in each environment | Created or linked by the deployment |
| Rollback on failure | Manual clean-up | Failed deployments roll back automatically |
| Designed in | Studio or Studio Web | Studio Web |
| Best for | A single process with few resources | A multi-process automation with many resources, promoted across environments |
Automating Deployments
Automation Ops Pipelines include solution activities such as Upload Solution Package, Deploy Solution, and Activate Solution Deployment. This lets teams add solutions to CI/CD, with approval steps before production.
Worked Example
A team builds an invoice solution in Studio Web with three projects: a dispatcher, a performer, and a reporting process. It uses one queue, two assets, one storage bucket, and a queue trigger.
- Publish the solution as version 1.0.0.
- In the test tenant, open Orchestrator > Solutions > Packages and deploy 1.0.0 to Shared with the solution folder name
Invoices, the runtime Default Serverless for the background processes, and Activate immediately turned off. - Review the configuration: set the test API URL asset, and link the storage bucket to the test tenant's existing
InvoiceFilesbucket. - Deploy. The status shows In progress, then Successful.
- Activate the deployment and run a test batch.
- Promote the same package version to production with production values.
If step 4 had failed, for example because a resource name already existed and was not linked, the deployment would roll back and show Failed.
Good Practices
- Keep environment-specific values, such as URLs and credentials, in the deployment configuration or in linked assets, never hard-coded in the projects.
- Deploy with Activate immediately turned off in production, check the configuration, and then activate.
- Use a clear deployment name and version so the Deployments tab shows what runs where.
Common Traps
- Solutions are designed in Studio Web; deployment happens in Orchestrator's Solutions page.
- The default location is the Shared folder, with a new solution folder created under it.
- A failed deployment rolls back; Failed Rollback needs manual attention.
- Existing resources can be linked instead of duplicated.
Where are solutions designed, and where are they deployed?
Designed in Studio Desktop and deployed with Assistant.
Designed in Orchestrator and deployed from Studio Web.
Designed in Studio Web and deployed from the Solutions page in Orchestrator.
Designed in Action Center and deployed by Integration Service.
A solution deployment fails partway through. What status is shown, and what happened to the resources?
Failed; the deployment was rolled back.
Successful; the missing resources are created on the next job.
In progress; it retries every hour until it succeeds.
Paused; an administrator must finish each resource manually.
The target tenant already has a storage bucket that the solution should use. What is the right approach?
Delete the existing bucket so the deployment can create it.
Rename the solution bucket so both exist.
Give up on solutions and deploy the package manually.
Link the solution resource to the existing bucket during deployment configuration.
Sections you finish are checked off in the contents.