Allow Migrations between Non-Production and Production workspaces that have separate SSO containers.

drt100

Our company, and I presume others, use a production and a non-production SSO environment for security purposes. We have our Anaplan workspaces setup to use them, accoringly.

 

However, the Anaplan platform does not support migrating code from two workspaces that do not reside in the same SSO container. 

 

We believe this should be supported at an overall Tenant / Customer level, and not limited to being in the same SSO container. The same would hold true not non-SSO non-production environments, with an SSO production environment... the end result is the same. Customers should be allowed to easily migrate between all of their environments when needed.

 

The current workaround is to have a tenant administrator swap the workspaces into the same SSO container, perform the migration, and swap them back - but that's not ideal for any of the parties involved.

frederic.denis

We have the same problem, my company makes sure that at any point of time, PROD data cannot be accessed from DEV and TEST. All DEV /TEST data [in Anaplan] are anonymized. We are working with French lawyers, so my company handle their data as highly secured / confidential.
This was the rationale behind building separate workspaces: a DEV /TEST user cannot access PROD, and vice-versa. This is also why we use 2 distinct Azure Tenants, with 2 separate IDP settings.
No account is created in Azure, all accounts in Azure result from a synchronisation (AD Connect) with our active directory on premise.

Users have separate accounts for TEST & DEV on one hand, and PROD accounts on the other hand. Some users have only Test/Dev accounts, others only PROD accounts, and some have both type of accounts; in the case of a person having access to both TEST/DEV and PROD, he/she has 2 separate accounts in Azure (see diagram below).

The Anaplan partner users currently connect exclusively to the DEV/TEST workspaces, authenticating through the ADN Azure DEV Tenant. They do not have access to PROD; their access may be considered at a later stage (through the PROD Azure Tenant).

The fact to activate 2 sso connections prevents the import and synchonization of models. We have to detach the workspaces of the sso connection (stop the production) to workaround and after reattach the sso connection. This is cumbersome and time-consuming.