Remember to upgrade your previous version CDS database to preserve Flow Approvals history or entity data

In January this year, Jim Daly provided a detailed announcement on the previous version CDS to the CDS for Apps migration experience that is available for self service. As the deadline to initiate the database migration is coming up, we want to help ensure everyone has considered if a CDS migration is required for their environments with a previous version CDS instance, and continue operating successfully.

This blog post is applicable to you, only if you see a “Upgrade Now” link in the Admin Center as shown in the screenshots of this blog post.

We also want to ensure that everyone understands that the data stored for the Flow Approvals feature is stored in the CDS instance in the Default Environment, and if their Default Environment has a previous version CDS instance, the tenant admin must upgrade this instance to preserve that data (Pending Approval Requests and Approval History). See the Flow Approvals documentation for more details.

Motivation

There are two main reasons to consider if your previous version of CDS instance needs to be upgraded:

1. Users are using the Flow Approvals feature

   If the organization uses the Flow Approvals feature, the data related to Flow Approvals is stored in the CDS instance of the organization’s Default Environment.  If the organization wants to preserve Flow Approvals history and Approvals currently in transit, they will need to upgrade the previous version of CDS instance in their Default Environment.

2. Users in the tenant need to preserve data in their previous version CDS instance

   If there are previous version of CDS instances with data the organization needs to preserve, these instances should be upgraded. This will usually only be possible if the users that created the database or custom tables in the database had the paid licenses or a trial paid license to use the premium CDS feature.

Understanding the role of CDS in the Default Environment

Approvals data are stored in the Default Environment’s CDS instance

It is important to understand that the Default Environment’s CDS instance is the database that stores the Flow Approvals data used throughout the entire tenant. When the first Approval request is sent on a tenant, a CDS instance is automatically provisioned in the Default Environment if one did not already exist. This is important to know because many might not have been aware of this change when using the Approvals feature, as it happens behind the scenes. If the Approvals feature is being used anywhere in the tenant, all Approvals history or currently pending Approvals data is stored in the CDS instance in the Default Environment.

If the Default Environment has a previous version of CDS instance with Approvals data and is not upgraded by the deadline, the Approvals data (history and pending Approvals data) will be deleted when the instance is deleted.

If the tenant admin decides to upgrade the Default Environment, he or she should be aware that Approvals functionality will stop during the downtime expected in step 3. Approvals history and pending Approvals will not be accessible by anyone until the migration step has completed.

Other Environments with a CDS instance do not store Approval data. Only the data that was added by the contributors will be in those instances.

Flow Approvals and licensing

Upgrade to CDS has no impact on licensing for Flow Approvals

Expectations for the Default Environment after upgrading

All users of the organization will get access to Model-driven app capabilities besides Canvas apps and Flow after upgrading the Default Environment to CDS for Apps. This does not necessarily mean they will be able to build Model-driven apps because a P2 license is required, but they can start a P2 in order to create Model-driven apps.

How Security Roles are impacted after upgrading the CDS in the Default Environment

The way database and environment permissions are managed in previous version of CDS is different than in the new CDS for Apps, so the upgrade will change how the roles are expressed. The security roles are managed in the CDS for Apps database, and requires configuration in the portal.

Here is how the security settings will migrate as part of the upgrade process:

1. In the Default Environment, all Global Tenant Admins for the Tenant will automatically have System Administrator role to the CDS for Apps database as well – see this documentation for the details about these predefined roles
2. Any Users configured as Environment Makers will be granted the following Security roles: Environment Maker & Common Data Service User roles – see this documentation for the details about these predefined roles
3. Any Users configured as Environment Admins in the Environment will be granted the System Administrator role – see the Environment permissions topic for more details
4. We don’t have the ability to configure security roles for Security Groups Hence we cannot automatically grant permissions to Security Groups in the new environment, so the administrator has to manually assign security roles to the users belonging to those security groups.

 

Previous version of CDS security roles	CDS for Apps security roles
Environment Maker	Environment Maker & Common Data Service User
Environment Admin	System Administrator

 

In the previous version of CDS we had the concept of Open database, where the data stored in the common data service was open to all users. For that setting, one could share apps and view data without having to worry about managing permissions to the data.

In the new CDS for Apps database, it uses role-based security model by default to secure access to the database and there is no concept similar to OPEN which everyone has access to. The Environment Maker role has no permissions to the database by default. The CDS User role can run an app in the environment and perform common tasks for the records they own (only for non-custom entities). One has to create or configure a custom security role to explicitly grant privileges to custom entities.

Deadlines and extension

If you intend to upgrade your previous version CDS database you must start the first step before March 15, 2019.

If you begin Step 1 of the upgrade before March 15, 2019 you can continue to complete the upgrade until the service is discontinued. We intend to continue the service until April 15, 2019.

If you do not begin Step 1 of the upgrade before March 15, 2019, we will disconnect your database and store your data for 30 days before deleting it. If you wish to reconnect a database, you must contact support before March 29, 2019.

If this data does not need to be preserved past the migration deadline, it’s safe to ignore the upgrade warnings and let the CDS instance get deleted automatically.

Once the database is migrated (or deleted automatically), Flow Approvals will work normally. When the first Approval request is sent on a tenant, a new CDS for Apps instance will be automatically provisioned in the Default Environment if one did not already exist.

Other resources

For more detailed information on how to upgrade a previous version of CDS instance, see the documentation here.