Copying a Talent Core HR environment

Praise be to Elvis (and certain lovely people in the Talent product team who shall remain nameless), the feature we’ve all been asking for since July 2017 is here… You can now copy a Talent Core HR environment.

There’s been some confusion around this for a while now. So let’s take a little bit of time to clear things up. Since October 2018 (ish) we’ve had the facility to copy a CDS environment. That meant that to some extent, you could replicate some of your Talent data from one environment to another. But those of you who’ve followed this blog or worked with Talent for a while will recognise the key shortcoming of this feature – not all the data that currently exists within the Talent Core database (which some of the dinosaurs among us know as the AX database – lovingly abbreviated to AXDB) is being synced to the Common Data Service. So yes, you could copy a CDS environment, but a significant proportion of the setup you’d done in the AXDB would be missing.

Now however all that has changed – and it’s possible to copy the Core HR database or AXDB from one environment to another. This change is being rolled out in an LCS update today – and I’m already seeing it in all the LCS environments I work within.

Right. Let’s go a bit deeper.

There are some controls around where you can do this – mostly consistent with Microsoft’s environment management strategy. Let’s consider what those are before we get stuck in to how you actually do this.

  • You can only copy a Production environment into a Sandbox environment, you can’t go the other way around. That means you can use Production data to create a mirrored Test environment, but you can’t use the environment copy to ‘promote’ config from a Sandbox to Production.
  • You can copy between Sandbox environments.
  • The environments you copy between must be located in the same region (can’t think of any legitimate reason why your Test and Prod environments would be in a different region, but I’m sure some will have tried it either accidentally or on purpose)
  • You can copy between LCS projects, but not between tenants.

Also – there are some key things you need to bear in mind:

  • All the data in your target database (the one you’re copying INTO) will be erased and can’t be recovered. Seems obvious, but worth stating clearly.
  • The environment you’re copying into can’t be used until the copy has completed. Also obvious.
  • All users except the Sys Admin users and service accounts are disabled in the newly minted environment, so that the admin users can anonymise data before releasing it to the world.
  • Again seemingly obvious but for some reason this caught me unawares – the newly copied target environment will inherit the user options from the source environment. I always set my Prod environment to red and my Test environment to green. After the copy my Test environment went red. I was very confused and spent ten minutes checking URLs (which by the way don’t change) to make sure I was in fact in my Test environment, before I could change the colours again.
  • Documents and templates in Azure blob storage don’t get copied.
  • The admin user will need to reconfigure any integrations – it can’t be assumed they’ll still work/be pointing at the right environment.

Ok, so how do you actually do it?

If you want to create a like for like replica, you complete the copy in two stages. First you copy the Core HR database (or AXDB), and then you copy the PowerApps environment.

Copying the Core HR database:

Log in to LCS

Navigate to the Talent project which contains your source environment (that is, the data you want to copy)

Hit the ‘Talent app management’ tile on the right hand side

Screenshot of app management tile

Select the source environment, and hit the ‘copy’ button

Screenshot of copy button in LCS

A slider will pop out asking you to identify your target environment. If you don’t see your target environment listed, check that it is a Sandbox instance (remember you can only copy into a Sandbox instance, not a Production one). If your Target environment is old (as mine was) and was created before Talent Sandboxes were a thing, raise a call with Microsoft to have it switched to Sandbox. You can’t do it yourself unfortunately.

Copy slider screenshot

Once you’ve got everything in place, pick the target environment from the list and hit continue.

When the job’s done, you’re supposed to get a message in the pop out slider saying that the job has completed. I didn’t – it just went blank. But the status in the app management grid changed from ‘in progress’ back to ‘deployed’.

There’s no progress indicator yet – and how long the process takes will vary according to how much data is being copied. In an environment with about 100 workers in it, the process took less than 15 minutes.

When the Core HR environment has successfully copied, you can copy your Power Apps environment too. That’s already well documented as you’ve been able to do it for a while, so I’ll just provide this link out to Microsoft’s guide.

After your Power Apps environment has also copied successfully, you need to re-enable the sync between Talent Core HR (the good old AXDB) and the CDS. It gets disabled as part of the copy process and you have to switch it back on. To do so, go to System administration > Links > Integrations > Common Data Service configuration, and make sure ‘Enable the integration’ is set to ‘Yes’.

CDS integration screenshot

Finally, you’re going to want to review your user accounts and re-enable the users who have legitimate access to the environment. Remember the user and role list will now have been inherited from the source environment, so some of the users who participate in testing will not the have the right roles and their accounts will have been disabled.

And that’s it. About 10 clicks that make the world a better place.

Happy Christmas Talent folks.

 

 

3 thoughts on “Copying a Talent Core HR environment”

  1. > If your Target environment is old (as mine was) and was created before Talent Sandboxes were a thing, raise a call with Microsoft to have it switched to Sandbox. You can’t do it yourself unfortunately.

    A better way, would be to delete the Target environment. It will be overwritten anyways if a copy happens from source to target. Thus deleting the Target environment and creating a new Sandbox environment would be a better and a faster approach.

    Reply
    • Cheers Amar – you’re right, that works too. I’ve found deleting instances to be a bit messy in the past, which is why I prefer to keep things clean and switch the instance type. But whatever works for you is cool.

      Reply

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.