Breaking news from around the world
Get the Bing + MSN extension
Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, PowerApps, Microsoft Flow, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates to Dynamics 365Release overview guides and videos Release Plan | Early Access Availability
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 | Talent TechTalks | Upcoming TechTalks
As we're reviewing how we're going to implement CRM, I just want to review some things regarding User records and Contact records. As a non-profit, we're likely going to have some custom entities linked to Contact records, such as Volunteers and Donors. And of course we'll have Staff members, most or all of whom will be CRM Users.
From what I've read, having a Contact record and a User record for the same person can get complicated, especially regarding email tracking (if they have the same email, for example). So it might seem to make sense to just have our staff as Users (or we might make a custom Employees entity, for more data, but it would link to the Users entity). But, cases definitely happen where people who are first Volunteers or Donors become Staff, and vice versa. So they'd already have a Contact record, potentially, or would need one when they leave. We really want to keep the info and history across these transitions.
So - I was pondering this. Volunteers and Donors and whatnot have a Contact record. When a person becomes a staff member, they would become a User (and get a corresponding Employee record automatically via workflow). If they already have a Contact record, the workflow puts a link to it, but maybe marks it inactive to cut down these conflicts? And/or asks for a personal email to put in there instead? When a person leaves, the User/Employee records are marked as inactive, and if the Contact was deactivated, reactivate it at this time.
Thoughts? Better ways to handle this?
This is the the most common approach - just ensure that your user records do not have the same email as the contact record at any time. You can use connections to join contacts to users to see history.
Hope this helps,
Normally I try to think of people in their personal capacity differently to their employment/work capacity and distinguish between the 2.
If someone is a staff member, they may very well also volunteer and donate to your organisation. That may well continue even if they become employees (especially if that's how they got to know about you in the first place). They are passionate about your organisation and long may that continue.
So... you do not want to treat (or even risk treating) your staff as second-rate donors/volunteers.
So I put their work email address and work phone numbers and work address into the User record (and I would use the OOTB User record unless you're needing to store confidential HR info, and even then with User/Manager-ownership of their own records, BU security and field level security it is rare to really need to add an additional entity).
I put their personal email address, personal phone numbers and personal/home address into their Contact record.
I continue to treat them professionally as a donor/volunteer as well as a staff member.
I also have a field on the Contact record to flag that they are a staff member (so if the communication has already gone out to all staff and would be redundant I have the option of excluding them for a mailout to dynamic mailing lists.
If they stop being a staff member then you just disable the user and remove the staff flag from their Contact record. HR can do that. You may even like to turn it into an option set: Staff member, Past staff member, Blank. Then you have a database of past staff members in your Contact database that may be useful information (depending on your staff turnover and any privacy concerns).
Note: In the case of donations by staff, you may want to move the $ transaction records into a different business unit so they are kept confidential from other staff, and managed by just one person. That shows respect for their dual roles, and the fact that they may not like all their colleagues knowing just how much they donate to a specific campaign.
Thanks to both of you! I have an aversion to having two records for the same person, as a general rule, but I can see where in this case it's probably the way to go. (That's how it is in our current system but we don't have any way to manage the connection so it's pretty messy/confusing).
Thinking about it a bit more (including your previous thread).... I try to clearly distinguish between:
Contact/Account: A picture of who this 'customer' is (with a 360 degree view / summary of past and planned activity, categorisations and 1:N links via sub-grids to any processes underway)
Activities: one-off interactions (not requiring special security)
Processes: entities that allow us to group and manage Activities.
Special Activities e.g. financial transactions - that are kept separate so that special security can be applied.
User: Special Employment role. No reason why you couldn't have a link to their Contact record from the User record if you wanted it. You could even label it 'Personal Details' (and even have a Contact Quick View form that showed key details like home phone on the user record) that way, if they had a Contact relationship with your organisation, you wouldn't need to keep any of those details on their User record as well / no data duplication at the detail level.
Business Applications communities