For existing Data Access Controls Customers (DAC) Only - Upgrade to Zuora Multi-Org

Last updated
Save as PDF

Data Access Control (DAC) allows businesses to customize and control user access within Zuora Billing. A hierarchy of tags were leveraged to enforce access to a Zuora object. This hierarchy of tags has a tree structure where tags are assigned to users and objects. However, certain constraints including no API support, and having no autonomy over user access controls led to the creation of Zuora Multi-Org.

Migrating from Data Access Controls (DAC) enabled tenant to Zuora Multi-Org.

There are 2 use cases where a business would want to migrate to multi-org. from their existing DAC-enabled setup.

Businesses can leverage the existing DAC tag hierarchy to create the new Org. hierarchy in Zuora Multi-Org. as a 1:1 mapping.
Businesses can create a brand new Org. Hierarchy in Zuora Multi-Org.

Upgrade to Zuora Multi-Org. with existing DAC tag hierarchy to create the new Org. hierarchy in Zuora Multi-Org. as a 1:1 mapping.

This section explains Use case 1 in detail on how a business that has an existing DAC-enabled tenant can upgrade to Zuora Multi-Org. using the same tag hierarchy created in DAC.

DAC Tag hierarchy.png

_{DAC Tag Hierarchy 1:1 mapping to Multi-Org. Hierarchy}

Here are a few terms and concepts to familiarize yourself before getting started:

Zuora DAC	Zuora Multi-Org.
Root Root is referred to as the global entity by default.	Root Root is referred to as the global organization (default parent)
Segments Children under the root level.	Org. Units Each of the children under the root is referred to as an org. unit.

Zuora DAC

Zuora Multi-Org.

Root

Root is referred to as the global entity by default.

Root

Root is referred to as the global organization (default parent)

Segments

Children under the root level.

Org. Units

Each of the children under the root is referred to as an org. unit.

Points to remember before upgrading a DAC-enabled tenant to Zuora Multi-org.

Data Access Controls only fetches the first status = Active, Value = Yes, Org. hierarchy ordered by index.
DAC customers must be enabled with Invoice Settlement capability to upgrade to Zuora Multi-Org.
DAC allows the removal of children and associated date after they have been added to an Org. Hierarchy with limitations on the ability to delete a node that has children under it.
In DAC, a user with access to the parent has implicit access to all the objects that are children of the parent.
In Multi-Org. objects are visible only if the user has explicit permission to access one or more Org. units.

For a DAC customer:

Originally there is a xxx__hfield where xxx is the hierarchy API name, in the API payload. Once the customer is migrated to Multi-Org. the xxx__h will no longer exist. This will be replaced by new organization-related fields including "organizationLabels", "organizationName" and "organizationID".

Existing API Payloads for DAC customers:

The following APIs have xxx__h field in their response body:

Method	URI	Field Path
`GET`	`/accounts/{account-key}`	`basicInfo.tags`
`GET`	`/accounts/{account-key}/summary`	`basicInfo.tags`
`GET`	`/catalog/product/{product-id}`	`tags`
`GET`	`catalog/products`	`products.tags`

The following APIs have xxx__h field in their request body:

Method	URI	Request body field
`POST`	`/orders`	`newAccount.tagging`
`PUT`	`/accounts/{account-key}`	`tagging`
`PUT`	`/orders/{orderNumber}`	`newAccount.tagging`

Steps to Upgrade to Zuora Multi-Org. Zuora Multi-Org. upgrade through API's

Upgrading an existing DAC-enabled tenant with the first existing active org. hierarchy among multiple org. hierarchies through a 1:1 mapping to the newly enabled Zuora Multi-Org. hierarchy has the following steps:

Cloning the DAC tag hierarchy to create the new Zuora Multi-Org. organizational hierarchy.
Label the key objects based on the DAC tags:
1. Customer Accounts
2. Products in the Product Catalog
3. Users
Repeat Step 2 to label all the key objects. Any unlabeled object shall be defaulted to the root (Multi-org Parent)
Review the audit log actively for labeling changes to the key objects.
Deactivate the DAC tag hierarchy.
Activate the Zuora Multi-Org. org hierarchy
Verify and activate Zuora Multi-Org.

See the Multiple Organizations API reference for details.

Since DAC already has an Active Org. Hierarchy, the first step in the upgrade process will be to sync this hierarchy with the new Multi-Org. Inactive org. hierarchy through the sync API. This will be the default Multi-Org. org. hierarchy with 1:1 mapping.

Next, you need to call the labeling function for each record in zb_tagging_cf with the org. unit name given in the new org. hierarchy created for Multi-org.

Once Multi-Org. is activated, a user will only have access to the data they are permitted to, your the org. admin.