Business rule deployment enables you to create, update, and test automations (beta) and triggers in your premium sandbox environment and then implement the same trigger and automation configurations in your production account without the risk of manually recreating it. This two-click solution speeds up the change management process and prevents keying errors, giving you more control over what’s copied into production. This article describes how to deploy trigger and automation configurations from a sandbox to your production instance.
About business rule deployment
- Sandbox-to-sandbox deployments are not possible. You can only deploy a business rule from a premium sandbox to production.
- The deployment happens immediately and can't be scheduled. You may want to deploy during off-hours or at a low-volume time of day.
- A deployed business rule can have no more than 100 dependencies. A dependency is any reference in a condition or action, such as a group or a custom field.
- The trigger or automation can't have any dependencies that are missing from production.
- After deployment, the trigger or automation may not be in the same position or category when it appears in production. After you deploy the business rule, you might need to reorder them or move it to the correct category to ensure it fires properly.
- Deployments can't be reverted automatically. You have to manually revert them in production.
- Deployments are recorded in the production audit log, so you have a record of the change.
Preparing for a problem-free deployment
- Replace your sandbox before making changes to it, so it’s the freshest version.
- To deploy triggers, ensure you’re working in a premium sandbox created on or after August 30, 2021. For automations, ensure you’re working in a premium sandbox created on or after May 23, 2022.
- Notify agents and admins of the time window when you plan to deploy the changes and ask them not to make any changes of their own during that time.
- When deploying an update to an existing automation, capture a record of the automation as it exists in production prior to the deploy. This will help in the event you need to manually revert the changes.
- If possible, deploy outside of business hours, or when there are fewer inbound tickets.
- Publish release notes to communicate the changes to admins and team leads.
Deploying business rule configurations from sandbox to production
After you create and test your trigger or automation in a premium sandbox, you can deploy it to your production account.
-
In your production account, open Admin Center, click
Account in the sidebar, then select Sandbox > Deployment.
- (Automation deployment beta only) In the Configuration type drop-down, select the type of business rule you want to deploy: Automation or Trigger.
- In the Premium sandbox drop-down, select the sandbox that has the trigger you want to deploy.
- In the list that appears, locate the trigger and click Next.
- If prompted, resolve any missing and duplicate dependencies, then click Next.
- Review your mapped dependencies and click Deploy.
After the business rule configuration is deployed, you can check it by viewing the trigger or automation in production and comparing it to the sandbox.
Resolving dependencies
A dependency is anything referenced in a business rule's conditions or actions, such as a group or a custom field. For example, in the following trigger condition, the combination of a custom ticket field called “Office location” with a drop-down option called “Winston-Salem” is a dependency.
![](https://zen-marketing-documentation.s3.amazonaws.com/docs/en/sandbox_deploy_trigger_dependency_example.png)
In preparation for deploying the business rule configuration, dependencies in a sandbox configuration are compared to the corresponding dependencies on production. If it can’t find all of them or identifies multiple possible matches, a list of the unresolved dependencies is returned. All dependencies must be mapped to production before you can deploy the business rule configuration.
Missing dependencies
- rename the dependency in your sandbox to match something in production
- create the equivalent object, field, option, or value in production
- From the Admin Center > Account > Sandbox > Deployment page in your sandbox, review the list of dependencies under Resolve missing dependencies.
A list of missing dependencies is displayed.
- If you need to create the dependency in production:
- Click Go to create next to the dependency.
- Create the missing object, field, option, or value making sure to match the dependency's name in the sandbox exactly. To make this easier, the list of missing dependencies includes a description, such as Group or Organization field option.
- If the dependency does already exist in production, but the names aren't identical, you can rename the dependency in either your sandbox or production.
- Back on the sandbox deploy page, click Refresh matches.
-
After all dependencies are mapped, click Next to move to the final step of deploying the business rule configuration.
Duplicate dependencies
A duplicate dependency happens when there are multiple potential matches in production for the business rule's dependency. In this case, you must select the correct item in production to map the dependency to.
- From the Admin Center > Account > Sandbox > Deployment page in your sandbox, review the list of dependencies under Resolve duplicate dependencies.
- In the Select match dialog, select the appropriate match and click Next.
If you're unsure of the correct match, you can click View to see it in production.
- Back on the sandbox deploy page, click Refresh matches.
-
After all dependencies are mapped, click Next to move to the final step of deploying the business rule configuration.
Deleted dependencies
A deleted dependency happens when a business rule you're trying to deploy has a dependency on something that has been deleted in your sandbox. In this case, you have two options: recreate the deleted dependency or update the business rule to remove the deleted dependency.
- From the Admin Center > Objects and rules > Business rules > Triggers or Admin Center > Objects and rules > Business rules > Automations page in your sandbox, find the business rule you want to deploy.
- Open the business rule and review the conditions and actions.
The issue might appear as an empty value in a condition or action statement, or might be highlighted. If you're unsure of an issue, click Save and look for the error messages.
- Remove the invalid condition and actions or update them to no longer reference the deleted dependency.
- Click Save.
- Return to the Admin Center > Account > Sandbox > Deployment page, and try your deploy again.
Reverting a deployed business rule configuration
There isn't an automatic way to revert triggers and automations that have been deployed. In the event you need to revert a deployed configuration, you can do so manually. If you deploy a new trigger or automation, you might just need to deactivate it.
Reverting a deployed trigger configuration
If you deployed an update to an existing trigger, you'll need to use the trigger's revision history to manually restore the conditions and actions to their previous state.
- In Admin Center, click
Objects and rules in the sidebar, then select Business rules > Triggers.
- Click the trigger you want to revert, then click Revision history. (This is located below the trigger title.)
We recommend opening the revision history in a separate tab.
- On the trigger history page, you’ll see all the available versions in a sidebar. Click the version you want to revert to and view its configuration, or you can turn on Show changes to see the most recent changes made to the trigger.
- On the trigger's details page, modify the trigger to match the earlier version and click Save.
Reverting a deployed automation configuration
Automations don't have a revision history. Before deploying an update to an existing automation, we recommend recording the current production settings, which you could use as a reference if you need to revert your deployed changes.
- In Admin Center, click
Objects and rules in the sidebar, then select Business rules > Triggers.
- Click the automation you want to revert.
- On the automation's details page, modify the conditions and actions to match the earlier version and click Save.
Checking the new business rule configuration in production
To check that the deployment happened correctly, compare the business rule configuration in production to the one in the sandbox. It may be easiest to do this in separate side-by-side browser windows.
Since triggers and automations run in order, it’s also important to check the location of the business rule in the list. It may not be deployed in the same order or in the same category as it appears in the sandbox. If that’s the case, move the trigger or automation to the correct location. This may entail reordering it (see Reordering ticket triggers or Reordering automations) or moving it to the intended category (see Organizing ticket triggers within categories).
14 comments
Joey
This is a very exciting feature but I'm not sure it's ready enough for usage in more complex instances. The main issue is that the creation of the Sandbox does not copy over all triggers/ automations, when there are issues with the fields or it's values.
Ticket sharing fields are considered inactive ticket fields and thus are not copied to the Sandbox. So now we are missing 30-ish triggers. Inactive triggers are synced tho (because that makes sense).
Using the whole deployment thing as it is now would be a pain, manage triggers in sandbox, unless they are related to ticket sharing, then manage in production. This obviously defeats the whole purpose of working in a sandbox and deploying. We want a consistent way of working.
Thus it would be nice if:
0
Shawna James
0
Joey
Thanks Shawna, but I find it more useful to give feedback and read about other user experiences within the articles.
0
Shawna James
1
Hannah Lucid
Will it ever be possible to deploy forms and fields from Sandbox to Live?
2
Chris Sos
Hey Hannah Lucid
Thank you for reaching out! We're excited to share that we do have plans to expand our deployable objects, with forms and fields on our roadmap. Stay tuned for updates as we roll out these enhancements in the coming months – your feedback is invaluable as we build out these features.
Cheers, Chris
2
Joey
@...,
Good to hear that deployable functionality will be expanded but please first fix these trigger issues.
0
Chris Sos
Hi Joey,
Thanks for the feedback regarding ticket sharing in sandboxes. We'll take this on for future sandbox enhancements.
Chris
0
Joey
Am I correct to understand that cloning a trigger in sandbox will make it not show up in the deploy list?
Steps: clone trigger in sandbox -> go to deploy screen -> notice the cloned trigger isn't there.
The original trigger shows up as changed, which it wasn't.
Edit: looks like it shows up when you archive it (probably any following save)
Edit edit: When adding a trigger in the middle somewhere it will consider all triggers below as changed so now you have to go through the whole list of triggers trying to find what you changed. In our case, we changed 12 triggers but now the deploy list has over 250 changed triggers on that day. Good luck finding those 12 with no search on that page.
1
mfg
Was just looking at the webinar schedule so me and the admin I'm training can learn more. There aren't any scheduled for the rest of the month or June. Will any more webinars be offered?
2
Ramakrishnan N
I am looking for a webinar in late May or early June.
1
Ramakrishnan N
@... …any update on this?
0
Danielle
Plus 1 on interest in scheduling a webinar session . I don't see any availability currently.
0
Jamie Noell
Overall, I really like the triggers/automations deployment except for 2 points, and we use this feature a lot. Excited for the new changes announced in the EAP!
Issues:
1. The over-notification of updated triggers due to trigger placement changes as described above.
2. I'll submit in product feedback but also want to check here if there are any plans for trigger deployment that include an email address (which typically shows as a conflict since the sandbox domain differs). With a similar product, Salto just looks at what's before the @ for the comparsion.
Example:
help@abc.com
help@abc-sandbox.zendesk.com
Because both have help@, then the trigger would deploy. We have to migrate our email routing triggers manually due to this issue.
0