Personalized Community is here!
Quickly customize your community to find the content you seek.
Check out the latest Sales updates!Learn about the key capabilities and features of Dynamics 365 Sales and experience some of the new features.
Download overview guide | Watch Sales video
2020 Release Wave 2Discover the latest updates and new features to Dynamics 365 planned through March 2021.
Release overview guides and videos Release Plan | Preview 2020 Release Wave 2 TimelineWatch the 2020 Release Wave 1 virtual launch event
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Upcoming TechTalks
One of our customers has the requirement to store internal employees within D365 Customer Engagement (CE) that don't have User licences for the CE system.
Reason: It should be possible to utilize some custom lookup fields (alternatively the Owner/User LU fields) to determine, who is the internal responsible for some todos outside of D365. Also we need to store/provide a staff number and email in CE for all employees and use that sometimes. And they want to be able to regularly import/update data for these non-user-employee records.
Usually you have three options to store employee data:- Contact entity- custom entity- Disabled Users
We already decided against mashing up the Contact entity with internal contacts.
So what are the decision criteria for a Custom Entity "Internal Employees" against Disabled Users?
Advantages leveraging Disabled Users:
- if we sync those Users with AD, we would automatically get updates of Names, Phone Numbers etc.
- to have only one table where all employees are coming from, whether they are CE Users or not: clear structure + easier to create Workflows / Processes as they don't need to make such big differences for CE vs. Non-CE-User
- follow the tip from Neil Benson here: create a field Former Employee on the User entity and change the Quick Find All Users view (and maybe some lookup views) to also include disabled Users but exclude former employees.
- you can then use them as Activity Parties for all Activities (Email recipients, 'Phone Call'.To etc. and also assign them Tasks etc.) as if they would be Contacts or Active Users
Disadvantages leveraging Disabled Users:
- need to either a) temporarily assign licences to these Users to get them created in CE and also assign them a Security Role in CE. Could be initially done in bulk by using Office Security Groups. The batch however could have at maximum the number of licences available. (Say you have 100 licences but 2000 employees, it would be 20 times the same tasks with a batch of 100 assignments each time). Or b) if you don't need AD sync you could also follow the tip from Nick Doelman here, where you import Disabled Users from an Excel.
- new Users would also need to temporarily get a licence assigned, so you would want to expand your onboarding processes
Advantages using a Custom Entity:
- clear difference between CE Users and Non-User-employees
- less effort to initially create them (no need to temporarily assign licences)
- can be enabled for some Activities as well. In Entity metadata the following should be enabled: Notes(not sure), Activities, Sending email: So the Custom Entity can than be used as Activity Partyes here: Regarding, Email.To, Appointment.Required, Appointment.Optional, Appointment.'Required Attendees', 'Booking Alert'.Assignees, 'Custom Activity'.'Required Attendees'.
- different icon for these kind of Activity Party vs. User-icon
Disadvantages using a Custom Entity:
- not auto-synced with your AD <=> I guess you could use Flow to automate this
- different table
- Workflows/Plugins need to go two ways when i.e. extracting the Staff-ID or other employee attributes. Option is here, to additionally create a Custom Entity record for all CE Users, but than you get these employees displayed two times if you want to add them as an Activity Party so that you need to precisely identify the icon of the record you're going to choose in lookups.
- new Users would need to be added manually (or by deploying Scribe/SSIS/MS Graph/Flow(?) to get these from AD)
- even after having enabled the Custom Entity for Activities (see above), here you won't be able to use it: 'Phone Call'.'Call To', 'Phone Call'.'Call From', Letter.To, FAX.To, 'Custom Activity'.To, 'Custom Activity'.From.
Are there any other Advantages/Disadvantages that speak for one of the options? I would highly appreciate your comments.
Having done this often in 2013 I just tested it again in 365 online with success. Using the import template, I imported a dummy systemuser -- the username & email address exist nowhere. It failed the first time when I tried to go directly to administrative license type, but did not blink when reset to basic. As in the past, the new user came in as deactivated which I assume still means there is no license required. So, maybe the batch limitation and licensing are not an issue.
I do leave it up to someone to test those limits again, but I succeeded in generating a single deactivated user without assigning a license, any security roles nor even a profile in Office 365.
Also, I'm assuming that if these are strictly non-using profiles one has no need to set up a mailbox for them; To, CC and BCC should do fine with them (again, I didn't test this.)
You've listed the main advantages and disadvantages of each. To me, the two most significant factors in your case are:
I know you already mentioned that you do not want to go for Contacts option but I came across a similar scenario and I found contact as the best option. Please see the details below
01. Created an Account record - Let's call it ABC Company - to keep all the internal employee contacts under one account
02. Add a field on Contact entity to have AD sam account user name (Domain\username or email) and possibly to hold SID.
03. Create Flow that gets all the users from AD, Loops through and checks if there is contact in CRM, if there is it could update the fields. If there is no Contact for an AD user, it can create a Contact. This will result in every single user in your company whether they are CRM users or not, to be a contact in CRM. This flow can be scheduled or manually triggered on demand - This flow will sync AD/AAD/O365 accounts to CRM Contacts.
04. Contact entity can be used in Activity Party list - One problem solved. You do not have to create a separate plugin or workflow. If you want to create a plugin or workflow just for internal contact, Workflow/Plugin/BR will just have to first check if it's an Internal Contact, it can do that by checking if there is an AD account.
05. if your flow runs let's say nightly, and if a user is added to CRM or Disabled, you might want to have workflow triggering on these events on User entity and Create internal contact for the newly added user or deactivate the contact if the user is disabled.
Personally, I think the disabled user approach is a workaround its not a permanent solution. I would definitely recommend you re-consider the contact approach its got more advantages than disadvantages in my view.
Business Applications communities