0

In our D365 online environment we have multiple sandboxes and production instances. In each of these the systemuserid is different (user import was done before I joined!!). This mismatch in SystemUserId is also happening when new user is added. (my own user record for example that was added last week)

I know updating systemuserid in onPrem was unsupported but was possible but with online environment what are my best options to fix this issue? With different Guids, all references (workflow etc) are failing when moving solution across different environments.

Coming here as my last option as I have googled and looked in to SDK already.

Thanks,

Kmria
  • 30
  • 5
  • The only supported methods of updating or inserting data are done via the API. In all environments, I believe. It sounds like a full refresh of your dev environments might be the only "easy" solution. – Jacob H Sep 20 '19 at 14:13

2 Answers2

1

You can't update an ID at all. I usually copy my production database in all my dev environment to avoid this problem. D365 also make it easy to do so. You should take a moment between two sprints to do it because it can help to have to system user ID and entities object type code identical everywhere.

Nick
  • 735
  • 5
  • 14
  • Interesting, does copying a production instance to a sandbox preserve the GUIDs of all the entities that are copied, even the "system" ones that are included in a Minimal one ? – Alex Oct 01 '19 at 14:33
  • It preserves everything. It can affect the system users domain name and organization settings because the import has to do a mapping with the new server/environment. – Nick Oct 01 '19 at 14:51
  • Copying production is also causing duplication in systemuserid. When we are adding new user through 365 admin portal and assigning user permissions to Dynamics CE, we get duplication in systemuserid again. This issue for me is in two part, fix existing guids and prevent future new user guids being duplicated. – Kmria Oct 01 '19 at 15:08
  • @Nick import, mapping ... are you referring to on-prem ? – Alex Oct 02 '19 at 07:01
  • Ya, I'm referring to on-prem but, of course, Azure will do it for you in this case. – Nick Oct 02 '19 at 17:49
  • Quick update: Despite SystemUserID been different in two environments, when we move solution from one environment to other, we are no longer getting reference error (solution with workflows that refers to a user in condition). So for now, this isssue de-prioritised. Not sure if MS is mapping users in the background at Azure AD level but it seems to know which user we are referring to. strange!! – Kmria Dec 02 '19 at 08:57
1

hardcoding data into processes is a bad practice, makes your processes really rigid. You can create a configuration entity, stab the sys admin id there and retrieve it. If you have a custom workflow activity you will be able to retrieve the record and use it in every configuration task.

Mauro De Biasio
  • 1,146
  • 6
  • 16
  • I been trying to sell this idea to the project manager from start and after looking into it, I feel this is the ONLY option I have. – Kmria Nov 04 '19 at 10:28