Deployment Manager Known Facts and Limitations

Workflow

• When the source tenant and the target tenant have workflows with the same name but different versions, the result of deployment is an incremental active version of the same workflow in the target tenant. Version increment is based on the last version present in the target. For example, if a workflow is present in both the source and the target, the source has versions 0.0.3, 0.0.2, and 0.0.1, while the target has versions 0.0.2 and 0.0.1. Following deployment, an incremental version of 0.0.3 will be created regardless of whether the user selected only 0.0.2 or 0.0.1.
• When a workflow is configured in the source tenant but missing in the target tenant, the result of deployment is a new workflow created in the target tenant with the same version as present in the source tenant.

Custom Objects

• The Deployment Manager supports the migration of custom object definitions.
• The Deployment Manager does not support the migration of custom object records.
• The provisioning for Custom Objects limit in the tenant is 10. The deployment will not succeed when this limit is reached in the target tenant, the deployment will not succeed.

Hosted Payment Pages

• You can deploy Hosted Payment Pages by navigating to Settings > Payments.
• The current version supports only the creation of Hosted Payment Pages.
• The Payment Gateway, Payment Method, and Payment Type fields are mandatory to deploy both in the Source and Target tenant. Ensure that the same type is configured in both source and target tenant.
• Manually deploy the Payment Gateway, Payment Method, and Payment Type in the target tenant before deploying the Hosted Payment Pages. Deployment Manager will support end-to-end deployment in the future release.
• Hosted domains and Callback Paths are environment-specific. They must be manually updated after deployment.

Accounting Period

The Z-Finance permission should be enabled by default to access the accounting periods under billing platform. Ensure that the user has Finance Permissions to create and update the accounting periods. For more information on Finance Permissions, see here.

The following is a list of known behaviors while deploying accounting period in the deployment manager:

1. This feature is available in Finance > Settings.
2. The open ended date in target tenant should exactly match the start date of any accounting period in the source tenant.
3. The deployment manager should be able to deploy all the accounting periods configured in the source from the common date as mentioned in point b.
4. The deployment manager does not consider open ended date from the source tenant for accounting period deployments.

Accounting Periods in Source Tenant:

Accounting Periods in Target Tenant:

Post Deployment the following Accounting Periods will be created in the Target Tenant:

Taxation

The taxation component is available as an individual component in the Select screen and can be found in Compare > Settings. For more information on the best practices to deploy the Taxation component in Billing, see here.

Taxation component has the following behaviors and a list of best practices:

• Connect tax engine has a dependency on custom fields. To ensure successful deployments, deploy custom fields before triggering the taxation deployments.

The following diagram depicts the deployment flow of the taxation components.

• Perform the following actions to deploy taxation component from source to target tenant:

1. Deploy Tax Engine as the master component, followed by the child components in the following order.
   1. Tax companies
   2. Tax code (dependent on tax engines and tax companies)
   3. Tax rate (dependent on tax codes)

• Deployment Manager deploys the tax companies associated with the tax engines that are configured in the target tenant. For example, if Source Tenant has Avalara and Connect Tax engines configured and the target tenant has only Avalara, only the tax companies of Avalara will be deployed post deployment and acts as a partial deployment.
• Deployment Manager does not support Open Tax Connectors from Marketplace.
• Make sure you test the connection of the tax engines under the setup tax engine.

Custom Fields

Zuora Metadata configurations have relationships in which one component controls certain behavior of the other component. Custom Fields is one such component that directly depends on the successful deployments of other components. It is recommended to deploy custom fields prior to deploying the following components:

• Taxation
• Billing Documentation
• Notifications
• Chart of Accounts

Following is a list of custom field settings:

• Custom Fields are selected by default when the user selects any of the above mentioned components. The user has the option to deselect/disable the component if custom fields have been deployed previously.

• Indexed custom fields cannot be updated to non-indexed; non-indexed custom fields cannot be updated to indexed.
• Custom fields associated with Accounting Codes cannot be deployed in the target.
• Custom fields cannot be reverted.
• Sharing the configuration for Custom Fields in Multi-entity is currently not amended in the Deployment Manager.

Custom Events and Custom Scheduled Events

• Custom events and custom scheduled events in the deployment manager service are available under notifications. For more information, see Manage Custom Events and Custom Scheduled Events.
• For successful deployments, Zuora recommends deploying the Custom Fields and Custom Objects before deploying Custom Events.
• Deployment manager compares and validates the custom events from the source through the name and base object of the custom event.
• Post deployment, a new custom event is created on the base object in the target tenant.
• Order Action and Order Action Processed Custom Event Notifications are available as out-of-the-box custom events in all the tenants. Hence they are not supported in Deployment Manager.
• To migrate custom scheduled events, the Name field is used as the primary key if the custom scheduled event is configured in both the source and the target tenant. In this case, a new event is not created; instead, the deployment manager updates the existing scheduled event.

User Roles

• Deployment Manager can support user role comparison in the current version. The support will be extended to deployments in the future release.
• Deployment manager does not compare and validate user roles for administration.
• Deployment manager compares and validates the custom roles on the name and the attributes within the role for comparison.
• The user roles can not be reverted once deployed.

General

• Deployment Manager does not delete the values of the parameters configured in the target tenant. For example, in the screenshot below, the values of Different Currencies remain false after deployment.

• If the Deployment Manager service cannot access a resource, such as a record or an object, it returns an error and displays the label "Retry-able Error". You can retry deploying the component after some time. In such a case, please get in touch with Zuora Global Support.
• Deployment Manager migrated the GL Segmentation Rules as a false value in target tenants. Activate the required GL Segmentation Rule post deployment.