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. In the newly provisioned tenant, "Retryable Error" label is displayed on the Compare screen. Click on any configured workflows and try again; this issue will be resolved.
• Cleanup Policy migrations are not supported. 

Custom Objects

• The Deployment Manager supports the migration of custom object definitions.
• The Deployment Manager does not support the migration of custom object records.

Custom Logic

Deployment Manager supports migrating Functions in Custom Logic. For more details, see Custom Logic.

The display names on the user interface of Functions are mapped to the following fields displayed on the Compare screen of Deployment Manager:

These mappings ensure the interface display names align with the corresponding fields in Deployment Manager during configuration comparison.

Hosted Payment Pages

• You can deploy Hosted Payment Pages by navigating to Settings > Payments.
• Deployment Manager supports the create and update action on the 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

• Deployment Manager will skip updating the custom field if the source tenant has a legacy custom field and in the target, it is an advanced custom field. Similarly, it will skip updating an advanced custom field in the source tenant that is configured as a legacy custom field in the target tenant.
  
  It is recommended that legacy custom fields be deployed and updated as legacy from source to target and advance custom fields be deployed and updated as advance. The system will display an error if legacy fields are deployed as advanced and vice versa.
   
• 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
  • Product Catalog
     
• Following is a list of custom field settings:
  • Custom Fields are selected by default when the user selects any of the above-mentioned components. However, 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.

Notifications

The display names on the user interface of Notifications may be mapped to the following fields displayed on the compare screen of Deployment Manager.

• Password/OAuth is set to default value as "Test". Changing this field needs to be done manually. If the URL used in the callout is global, there is no action required. If it is environment specific, it needs to be changed manually.
• Merge Field is not supported.
• For successful deployments:
  • Deploy Custom Fields, Custom Events, and Scheduled Custom Events before deploying Callout Notifications.
  • After deploying Callout Templates (for both creation and updates), manually update the password field to ensure proper configuration.

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.
• 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.
• Deployment Manager does not support the migration of user roles.

Reporting

• Deployment Manager supports reports that are stored within “My Shared Reports”.
• The primary key for comparison in reporting is Report Name and Data Source
• If the source folder structure exists in the target, but it hasn't been shared, the reports won't be migrated unless the customer manually shares that folder. 
• Reports located in other folders for e.g. My Reports will not be migrated.
• Download CSV and history details of Reporting deployments is work in progress. We will be supporting them in the Deployment Manager.

Following are the reporting deployment scenarios

1. When both the source and target have the same folder configuration

2. When the source includes a folder and report path definition, and the target tenant does not have the corresponding folder and report

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." After some time, you can retry deploying the component. In such a case, please contact Zuora Global Support.
• The Deployment Manager migrated the GL Segmentation Rules as a false value in target tenants. Activate the required GL Segmentation Rule post-deployment.
• Deployment Manager does support the export of Product Catalog and Reporting comparison.