Body
This article provides an overview of how to use the Configuration Import/Export feature to copy configurations between your Sandbox and Production environments.
Configuration Copy Process
When copying configurations from Sandbox to Production, you should follow these steps.
- If you are a new customer, wait until your Sandbox has been copied from Production for the very first time, so that the Sandbox is connected to the Production environment and the ticket, asset, and client portal application IDs match between environments.
- Build the new or changed configuration in your Sandbox environment, and perform any testing and review you want to do to make sure it's ready before you copy to Production.
- Export the configuration from your Sandbox environment. The export is saved to a local file, which you will need for the import process. You can keep the file afterwards, which you may wish to do since the export records will be replaced when the sandbox environment is next refreshed.
- Recommended: Import the configuration in your Production environment in test mode by running the import with the Execute checkbox unchecked. This will give you a summary of what the system detected was different between the import file and what's currently configured and a summary of what would be changed.
- Run the import again with the Execute checkbox checked. This will run the import itself and update the relevant configurations.
- Verify the changes by viewing the import results and by viewing the configured Service, Form, or Workflow.
Contents of a Configuration Export
The configuration export/import feature allows you to copy a Service, Ticket Form, Project Request Form, or Ticket Workflow. Whenever you copy a configuration, all of the dependent configurations that are related to that configuration are copied as well. For example, if you export a Service, the export will include the following, if they are configured:
- The Service itself
- The service's child Service Offerings
- The Service's and Service Offering's custom attributes
- Those custom attributes' definitions
- The Ticket or Project Request Form that is used by the service
- The form's attributes and their definitions
- The groups that are used by the service's permissions
- The workflow that is automatically assigned by the service
- The steps in the workflow
- The people associated with the service, or any of the other components
- ...and so on
The full list of exportable objects can be found in the Matching Rules for Configuration Copying article.
Note: Automation Rules are not included in the configuration copy, so if you have a service that is set up to trigger an automation rule that applies a related workflow, the workflow will not be included in a Service export. In this case you may want to export and import both the Service and the Workflow, and then configure the automation rule manually.
Source and Destination Environments
The configuration copy process relies on some assumptions about the source and destination environments. It assumes that the source environment (sandbox environment) is a similar copy of the destination environment (production environment) for some of the matching, and for anything related to application definitions. This means that if you copy a configuration from one specific application (either a client portal or ticketing application), that application must exist with the same ID in the destination environment in order to be updated.
The system also will track the date that any Sandbox environment is refreshed from Production. You can view this date at TDAdmin > Organization Settings > Export/Import Configurations. This date is used when matching to identify if an item is new in the source environment or already existed in the destination environment and should be updated.