Personalized Community is here!
Quickly customize your community to find the content you seek.
Have questions on moving to the cloud? Visit the Dynamics 365 Migration Community today! Microsoft’s extensive network of Dynamics AX and Dynamics CRM experts can help.
2022 Release Wave 2Check out the latest updates and new features of Dynamics 365 released from October 2022 through March 2023
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
We have a challenge related to the Dynamics CRM security architecture.
We need to categorize our customers based on which sector they belong to. For example
Education, Health, E-Commerce, Govt, Corporate etc.
We need to have different teams (Education-Team, Health-Team, Ecommerce-Team etc.) responsible for managing each type of customers. Each type of customers should be visible to their respective team of users or their managers only.
In some cases, a customer can belong to more than one sectors (Education, Health etc.), in such cases more than one Teams (Users and Users Managers) will have access to the Customers but we only want to share Customers (nothing else) between the teams, for example we don’t want to share one team’s Opportunities/Quotes/Orders with other another team even if the customer itself is shared.
We also need Top managers to have access to all Customers and related information.
Our recommended solution is to do it through teams. We will require to have two teams per sector, which will be Sector-Customers and Sector-General, for example for Education it will be Education-Customers and Education-General. Users belong to Education-Customers will have access to the Customers and Users belong to Education-General will have access to all other information of the Customer.
Security level will be user based, when a new customer is comes in, he will be owned by a default customer and he will choose the sector of the Customer. Based on the selected Customer’s sectors, the Customer will be shared with respective team. For example, of if the Sector of the customer is Education, the Customer will be shared with Education-Customers Team.
While creating other records for example Opportunities, the user will specify the “Type/Sector” of the Opportunity and the Opportunity will be shared with a team based on Opportunity’s Sector.
Can we have your expert opinion on this structure?
What mechanism are you using to assign the sectors to the customer? Are you using boolean (excuse me, 'Two option') fields to do so? Perhaps are you using a lookup to a separate, custom entity (table) where more than one sector can be assigned to a customer?
Are you defining views based on the sector(s) assigned to the customers? Are you planning on using system views or custom views for this? There are some remaining security questions to consider in this area.
I'm not really fond of the idea of managing sectors on both accounts and opportunities. This means you'll be managing this in two places instead of just one place. You could conceivably configure the system to 'carry over' the sectors into the opportunity from the account - but this assumes that you'll be creating all opportunities in this fashion - and you'll likely need to control this 'somehow.'
What mechanism will control the ownership of new customers? I'm a bit confused about how a customer can own another customer. It occurs to me that you mean that there is one person (owner) that will be responsible for assigning the sectors - but this amounts to a single point of failure - so you need to ensure that you have a backup structure in place to prevent all work from stopping.
In your mind will the assigning of teams be automated once the sector is assigned. Are you planning a workflow, a plug-in, or a workflow enabled plug-in to handle this aspect?
As a general rule, the suggestion is to either keep security (i.e. visibility of the objects) either locked down completely at the start and then open up specific objects (with a lot of testing) or vice versa - that is, start with security relatively 'loose' and then tighten up (with a lot of testing).
The scenario seems relatively standard for a sales-process. You'll need to monitor and have the right controls in place to ensure it works correctly. I believe that if this is done correctly, that you'll be successful in the long run. There used to be some concern about overrunning the principaluserobjectaccess when using a mix of teams and users - I'm not certain if this is still the case. Microsoft doesn't seem inclined to discuss this with me - so it remains unclear.
Thanks for your response.
We have not decided yet about the mechanism of assigning sectors to customers, we will either go with Option Sets (As don't expect too many sectors) or a Lookup (Custom entity).
Regardless of wither we define different views or same views for all kind of customers, we will handle the data based on security roles/privileges, which means that if the user has enough permissions he will be able to see the records.
The reason for managing the sector at both Customer and Opportunity level is that a Customer can belong to more than one sectors, a user can also belong to more than one teams (Team-Govt, Team-Education), so it will be hard to automatically populate sector at Opportunity level.
We are thinking about user level security, so the person who create the Customer will become the owner and then he can share it with any team by assigning sector to the customer.
Once the sector is assigned to the customer/Opportunity, we will have a workflow which will take care of sharing it with relevant teams. Any child records (Activities, Quotes, Orders etc.) will inherit security permissions from its parent (Customer or Opportunity).
Business Applications communities