Making the Case for Using Access Teams in Dynamics 365

Today’s blogpost is intended primarily for business/technology people who are planning a CRM project and have a business model that involves either:

In more general terms, if you have a collaborative business model where a unique set of unknown users will be required to add value to the business process – this post is for you. It’s ok if you don’t know what we mean by unknown users prior to business process completion. That’s why we’re writing the article… so, please keep reading. This article is not meant to be how-to on setting up Access Teams. Please go here to learn about implementing Access Teams. Also, Microsoft and other blogs have covered Access Teams to include all sorts of abstract technical details if you are looking for something more technical. This post simply illustrates Access Teams through real-world business examples.

If you don’t know about Access Teams, then a little bit about them (also this is a great resource). They were introduced in CRM 2013 and include added capabilities when it comes to teams and records. A very high-level overview of Access Teams:

The Entity must be enabled for Access Teams, followed by the creation of an Access Team Template that contains one or many Access Rights (User Privileges): Read, Write, Assign, Share, Append, Append To, and Delete. The Access Team Template is added to a form as a sub-grid. An Entity can have a maximum of two different Access Templates. We can develop programmatic controls automating this process to deliver solutions for very complex security requirements while leveraging out-of-the-box features.

Many of our clients are moving to new business models with highly collaborative business processes, with very complicated business rules for sharing records/data. To meet these requirements, the traditional security solutioning models need to employ a test case that considers Access Teams. You may ask why, especially since CRM is a platform on which developers can create customizations around data access that meet these requirements without using Access Teams. Well, we have seen these customizations after they’ve been built... they sound great until you try to manage or make changes to them due to business rules changing. Access Teams operate differently than traditional security roles. For instance, unlike the traditional security roles, Access Teams won't be cached because the system does not perform privilege or ownership checks (go here for more info). This is different than the traditional CRM security roles and has advantages. Conversely, Access Teams work by providing a User access to the record automatically using the privileges defined by the Access Team template for that entity type (more info here). This is good for system performance and simple to manage change and understand!

So, the above has been a lot of sizzle… now for the steak. Below are two real-world examples for employing Access Teams.

Example 1: The case for a large volume of Access Teams

This example is about managing teams that interact with customers. The source is an enterprise operating nationally and selling services using a B2C model in which leads interact with Inside and Outside Sales. The details of this example are described below:

Sales Process Information

  1. Inside Sales team receives 40K web/direct-mail/telemarketing leads weekly.
  2. Inside Sales team books appointments for Outside Sales team.
  3. Outside Salesperson gives a presentation to the lead. The company's sales process is a single presentation/appointment-close.
  4. If lead is not closed after first presentation, Outside Salesperson remains case owner; Inside Salesperson can work/follow-up/solicit.
  5. Lead is deactivated 90 days from first interaction with Inside Sales.

Business Rules

Solution (as a caveat, this is the Sales Access Team portion of the solution)

Because of the robust nature of the CRM security model, several different options exist here. Of course, we’re looking at an Access Team-based solution for these reasons:

Inside Salesperson (who is also currently the lead owner) books appointment for presentation. Lead is then assigned to an Outside Salesperson. The system passes Inside Salesperson’s Username onto the Lead form, called the Lead Access Template, which has Access Rights of Read, Write, Append, and Append To. This allows the Inside Salesperson to continue working the Lead throughout the 90-day window.

Example 2: User must own record, variable team size, and other complex requirements

A B2B technology company sells a solution via a Partner Channel. The details of this example are described below:

High-level Overview of Opportunity Sales Process

It consists of a collaborative team from various functional units who also happen to be in different CRM Business Units. The Opportunity Sales team members depends on geography, product and deal size attributes. Many of these factors are unknown at the creation of the Opportunity record. Below is a list of functional areas the Opportunity sales Access Team may be a part of:

  1. Channel Sales
  2. Channel Marketing
  3. Engineering
  4. R&D
  5. Legal
  6. Credit

Business Rules

An Opportunity Access Team consists of CRM users determined by four geographic attributes, eight product families, and four categories of deal size and/or solution complexity. Below are additional business rules.

Therefore, an Opportunity Sales Team may consist of between 6-12 CRM users collaborating on the Opportunity.


Again, because of the robust nature of the CRM security model, several different options exist here. Of course, we’re looking at an Access Team-based solution for these reasons:

The high-involvement team members like the Channel Associates, Channel Marketing Regional Lead, and Channel Marketing Manager require record Access Rights that allow Read, Write, Share, Assign, Append (links Opportunity record to other records), and Append To (if other records are linked to the Opportunity).

The low-involvement Team members like Legal, Product Family SME, R&D, and Credit require Access Rights that allow Read, Append (links Opportunity record to other records), and Append To (if other records are linked to the Opportunity).


These two examples illustrating Sales and Opportunity business processes are good candidates for employing Access Teams. If your business process requirements can be described at a high level like any of the below, we recommend considering employing an Access Team model:

For more information, please see these excellent resources:

Happy Dynamics 365’ing!

MS CRM Custom WCF with Dual Encryption

This allows the MS CRM custom WCF service which is hosted in MS CRM IIS server to be accessed from Client in a more secured fashion. The message payload sent from the client will be encrypted over the SSL as well as with the Certificate.

The purpose of this implementation is to provide a dual layer encryption of the message body and also authenticates the request by using a service account.

In this blog we will discuss implementing WCF with the following requirements:

  1. Implement MS CRM using a custom WCF service (SSL over https).
  2. Use WS-Security to allow the message payload to be encrypted with a certification.
  3. Authenticate the client with a service account.


The image below is a pictorial representation of how a request is submitted to a server which then in turn calls the MS CRM Custom WCF service to push the request to the MS CRM system.


Below are the steps to implement the WCF solution.

1. Implement the MS CRM custom WCF service SSL over https.
Once the WCF service is deployed to IIS, add the https binding and choose the appropriate certificate. In the following scenario, the certificate is a wildcard certificate.

2. Use WS-Security to allow the message payload to be encrypted with a certification.

In order to encrypt the message payload with a certificate, add a custom binding which will provide message security and will also host the service on SSL. This will allow the client configuration file to auto generate the encoded token value. The custom binding is as follows:

WCF service Web.config

Create a custom binding with the security authentication mode as "UserNameForCertificate".

Add a behavior with httpsGetEnabled = "true" and add the service certificate as mentioned below.

Add a service section as below. "BindingConfiguration" is pointing to the custom binding which is defined in step 1 above.

Client's Web.config/app.config

When the WCF service is added as a Service reference on the client app, the server certificate encoded value is auto populated as shown below.

3. Authenticate the client with a service account.

On WCF Service

Add the following appSettings to the WCF service web.config.

The following code snippet is used to authenticate the user (usually the service account details are passed from the client) who is requesting access to the service. This code should be written into the WCF service.

On Client Service

On the client service, before calling a WCF method, it needs to pass the user credentials (usually a service account) as shown below.

MSDN blogs

Happy CRM'ing!

Administering Team-based CRM Security in Changing Organizations

Traditional security management within Microsoft Dynamics CRM involves assigning a security role to a user or group of users. If the user changes roles, a new security role should be assigned. When job roles change, existing security roles need to be updated. Team-based CRM security can improve this process.

This role-based security management may work for some organizations, but it can be difficult to maintain when you have many users, users frequently change jobs roles or business changes often require you to create a new security roles. If that sounds like your organization, you should consider an alternative—a team-based model.

Team-based security may simplify CRM security administration for organizations that are experiencing rapid growth and/or transformation. In team-based security, the security roles are based on the entities rather than business roles. They remain consistent and are assigned to the appropriate functional CRM security-based teams. Then the users are assigned to the teams that align with their business functions. This way, as the organization changes, you need only understand how users align to functional teams rather than administer a long list of security roles.

This approach requires a fair amount of up-front analysis and setup, but take heart. It's all for the sake of your long-term CRM administration sanity!

How to Create a Team-based Security Model

Here's how to set up team-based security.

1. Analyze and document how teams and groups use CRM throughout your organization. For example, how many positions are in the Sales department? How does the Sales Manager use each entity differently than the Sales Consultants? What about in Customer Service and Marketing? Do all users in a department use the same entities, or are they divided into subgroups that work with different entities? Within departments, start grouping users together based on how they use CRM, such as:

These groups will form the basis of your CRM Security-Based Teams.

2. Create two security roles for each entity your organization uses: Read/Append and Create/Edit.

The picture below shows what the Read/Append security role looks like for the Campaign entity. Apply permissions on Read, Append, and Append To. Don't apply security permissions to any other entities in this security role.

You'd name this security role Campaign – Read/Append.

This is the Create/Edit security role for the Campaign entity. It includes the same access permissions of Read/Append, plus Create, Write, Assign, and Share. Don't apply security permissions to any other entities in this security role.

You'd name this security role Campaign: Create/Edit.

Set up a Read/Append and Create/Edit security role for every entity your organization uses. Setting up security roles based on how each entity is used creates a consistent foundation that will never leave you guessing which security role allows what access permissions. It also allows granularity in team permissions, as we'll see in the steps that follow.

(Note: Best practice is for Delete privileges to be limited to select users, such as System Administrators, not on these security roles. Alternatively, you could create a specific security role for Deletion privileges on an entity and assign it to select users or teams.)

3. Identify and document how each group in your organization uses each entity. Which entities does the group use? Do the users in this group Create/Edit records in this entity, Read/Append them, or do they not need permissions to the entity at all? Do all the users in each department require the same access permissions on the same entities, or is there a "Super" group who Creates/Edits on a particular set of entities and a "Basic" group that Reads/Appends?

4. Create the Security-based CRM Teams. Give the teams names that align to their business function or department, followed by their overall level of engagement with CRM, for example "Sales – Super." Ensure to select the team type of Owner.

Here is an example of what a list of teams may be named once they are created:


5. Assign the appropriate security roles to each team. In each team record, click Manage Roles.

Then select the Security Roles that align to the group's departmental responsibilities and level of engagement with the entity: Read/Append or Create/Edit. Keep in mind that a group may not require a security role on every entity. This provides the added benefit of a cleaner site map and navigation for teams.


6. Assign each user to the team(s)
that align to his or her department and level of engagement. Click the + sign in the User sub-grid to add users to your teams.

Now you are ready to administer security based on teams rather than security roles! Simply view the team's security roles and you'll never have to guess about a user's access permissions.

Keep up with business changes and transformations by:

Team-based security can take the pain out of CRM administration in a fast-changing organization. Go forth and administer!

Happy CRM'ing!


Microsoft Dynamics CRM 2013 Business Units and Data Silos

One of the truly powerful features of Microsoft Dynamics CRM as a business application platform is its built-in security tools. The security framework that CRM provides allows an organization to build security rules for their data and users with little need for advanced technical knowledge or database administration.

One misunderstood fact about CRM security, though, is that the use of business units within the security model will inherently silo data. For example, you often hear that because users "belong" to a single business unit that they won't be able to gain access to records that are owned by other users that are not part of the same business unit.

That is not inherently true. It is actually the combination of a user's security role, the security role's privileges (access rights), the access level of those privileges, and the owner of a record that define whether another user can read, write, or update, etc. a record.

To help understand how this works, consider the following definitions of the Dynamics CRM security components:

Business UnitA scoping mechanism that defines a grouping of users for security modeling purposes; business units are hierarchical in nature. Business Units are a framework upon which a security model is built.
Security RoleA collection of privileges (that are given a name) that reflect common user roles of your organization and/or business units; security roles are assigned to users or owner teams. See below for more details on Security Roles.
Privilege (access rights)The definition of a specific type of data access or action that can be granted as a right; privileges are granted through a security role and are cumulative. The following Privileges that can be assigned:

  1. Create
  2. Read
  3. Write
  4. Delete
  5. Append
  6. Append To
  7. Assign
  8. Share
Access LevelWhile the Privilege defines the type of data access, the Access Level defines exactly to which records the privileges apply. You can assign the Access Levels of:

  1. None
  2. User
  3. Business Unit
  4. Parent: Child Business Unit
  5. Organization

For example, if you assign Read privileges to a Security Role at the Access Level of "Business Unit", users with that Security Role will only have the privileges to see records owned by a user within their Business Unit.

For example, take the following security settings for the Salesperson security role on the account entity:

CRM 2013 Business Units and data silos

This combination will silo account records, meaning only a salesperson that belongs to the same business unit as the owner of an account record will be able to view that record. This is accomplished by configuring the settings as such:

But, if you change the access Level of these settings to either Parent: Child Business Units or Organization, this allows users from outside the owner's business unit to view the record. For example:

This configuration will allow a salesperson to view any account record that is owned by a user within their business unit or any child business unit.

And this configuration:

This combination will allow anyone to view account records, regardless of what business unit they are in, as the access level is set to Organization.

So, while you can use CRM 2013 business units to silo your data (it is indeed one of the most common reasons organizations utilize business units), it is not the inherit usage of business units that define whether the business units will silo data. Instead, it is the combination of the security role, privilege, and business unit-related access level that allows you to silo the data.

And you can imagine, with so many different configurations of these important security components (Business Units, Security Roles, Access Levels and Rights), the options are extremely vast. Understanding how these critical concepts work together will allow you to build complex and powerful security models into your CRM application.

Happy CRM'ing!

Security and Access Teams in CRM 2013

Are you looking for information about the security and newly available access team functionality for Microsoft Dynamics CRM 2013?  You should take a look at Microsoft’s Scalable Security Modeling with Microsoft Dynamics CRM 2013 whitepaper.

Microsoft’s security model offers lots of flexibility but can be challenging to learn, particularly when trying to understand where the various security components overlap (business units, security roles, teams).  This whitepaper is useful to help get used to the terminology of the security concepts and tools in CRM. The example scenarios will help you determine how you can setup security in CRM to suit your business needs.

Security and Access Teams in CRM 2013

For more information on the topics of security and access teams in CRM 2013, PowerObjects has a couple of helpful blogs you can reference:

You can also watch this Microsoft Dynamics CRM 2013 MVP Panel Chat for more details about all things 2013, featuring our very own Microsoft Dynamics CRM MVP Alex Fagundes.

Happy CRM’ing!


Using Office 365 Security Groups to Control Microsoft Dynamics CRM Online Access

If you are a Microsoft Dynamics CRM Online system administrator, you probably know that initial CRM user setup is performed in the Office 365 portal and then configured within CRM. But you may not know that you can use the Security Groups feature in the Office 365 Portal to enable or disable CRM access to custom groups of users you can create.

This feature can be useful for different scenarios, including:

There is actually a default security group that is pre-configured for Office 365 called System Administrators. This group includes all Office 365 users with global administrator rights.

Here's how it works. You must have global administrator rights in the Office 365 Portal.  If you do, log in to the Office 365 Portal with your credentials to the home page. Once logged in, do the following:

  1. On the home page, select the Users and Groups link on the navigation menu on the left side of the page.
  2. This will take you to the Active Users list. In the upper near left of the page near the top center of the home page, you will see a link for Security Groups. Click on the link to take you to the security groups management pages.
  3. Left click on the + (plus) symbol to create a new group. This will open up a new page where you can enter your new security group name.

Office 365 Security Groups

For this scenario, we will call our group Testing Users. This group will comprise of users that will have access to the CRM environment for testing new solutions. To create the group, do the following:

  1. On the entry page, enter the name of the group in the Display Name section.
  2. Next, left click on plus sign in the Members section to pop out the user selection tool to select the user(s) that will be part of this group.
  3. After entering the name, select Save in the bottom right corner to save your group.

security groups img 2

Voilà! Your new security group is created. Now, let's use it to limit access to Dynamics CRM Online to our Testing Users. Go to the Office 365 CRM Online Admin Center by first clicking on the Admin dropdown on the Office 365 navigation toolbar, then selecting CRM from the dropdown list. This will open the CRM configuration page.

security groups img 3

Next, select the CRM Online instance (if you have more than one) you want to edit and select the Edit button.

security groups img 4

In the edit screen in the security settings section, use the search tool to look up your new Testing Users security group and select it.   Click Save to save your selection and return to the main page in the Admin Center.

security groups img 5

security groups img 6

Then, click Save on the Admin Center page to save your CRM Online instance security settings.

That’s it! As long as the users in your group are licensed for CRM Online, access to the CRM Online instance will be restricted to the users in the security group. Other licensed users inside of CRM Online that are not in the security group will be disabled. To restore access, simply go back to the CRM Online Admin Center for that instance and clear the group name from the security settings.

Happy CRM'ing!

Control Access to Business Processes by Security Role in CRM 2013

One nice feature that is supported by the new business processes in CRM 2013 is the ability to control who has access to specific processes by security role.

For instance, in the example below, I've created a process called "Deactivate Account" to allow someone to deactivate an account. However, I want to limit who has access to this process so that only a few administrative people can perform it.

Follow the steps below to learn how to control access to business processes in CRM 2013.

  1. Navigate to the business process flow screen that you want to control permissions for—in this case, it's the "Deactivate Account" process. On the top bar, you will see a button called Enable Security Roles.

Control Access to Business Processes

  1. After clicking on that button, you will get the screen below.

At the top of the screen, you'll see two options:

Choose the second option to enable only for selected security roles. In this example, I have provided this role only to the system administrator and the sales manager. Anyone else who goes to choose what business process they wish to run on an account will not see the "Deactivate Account" as an option to choose.

As you an see, a few quick clicks should help you manage access to your business process flows. For more information on how to use this new feature, view our blog on creating business processes in CRM 2013.

Happy CRM'ing!

Assigning Records to Inactive Users in Dynamics CRM

Good day, CRM users!

Assigning records in Dynamics CRM has always been fairly straightforward. You have a record owned by your own user, and you want someone else to own it. So you assign it, and you're done. This could be done via the Dynamics CRM user interface or programmatically using .NET code, SSIS, Scribe or other tools that connect to the Dynamics CRM web service.

Assigning Records to Inactive Users

There are considerations to keep in mind regarding this, however. One primary consideration is that you cannot assign a record to a user that has been marked as inactive or disabled in the system. This makes sense on the face of it, but it can get you into problems in certain situations.

Consider a scenario where you are migrating data from a source database to Dynamics CRM. The source database has a set of users that own data in the legacy system, but are no longer with the company.

Obviously you would not want to create users for these former employees as you would have to pay for additional unnecessary licenses. However, you would probably like to maintain the historical data about the records these former employees owned. In the past, you had to either assign the record to a default user and have some sort of reference field to indicate the former owner, or do away with the historical data.

Well, no longer!

Assigning Records to Inactive Users in Dynamics CRM

A small, quiet, but rather important change took place sometime ago on the way the CRM database handles assigning records to inactive users that many may not be aware of. So long as the inactive user still maintains a security role, even though it is inactive, you can programmatically or via the UI assign records to that inactive user. This means that you can maintain the historical data of who owns a particular record even though they may no longer be with the company, and save yourself some extraneous licenses as well.

Pretty cool! Happy CRMing!

Duplicate Detection and Security Roles in Dynamics CRM

The duplicate detection functionality in Microsoft Dynamics CRM was developed to help you maintain integrity of your data. You can configure duplicate detection rules for any entity in CRM. The duplicate detection can be used during the creation of a record, updating a record, during imports or as a scheduled job.

One thing to note is that the duplicate detection setting only allows you to check against records that you have access to in CRM.

Let's say, for example, that a salesperson attends a conference and receives a handful of business cards. He would like to create them as leads in CRM to validate that they actually want to do business. Currently, this user has full access to leads, but his access to the accounts and contacts are only for records that are in his business unit. The system administrator created a few duplicate detention rules to help prevent duplicate data in the system:

1. The first rule was set up to check against existing leads.

duplicate detection with security roles

2. The second one was to check the first name, last name and email address of the lead against existing contacts.

3. The last one was to check the company name against the account name in the account entity.

With these three duplicate detection rules setup in CRM, the system administrator believed they could catch all records that may have been duplicates. What the administrator didn't realize is that when the duplicate detection functionality is run by the user, it only checks against records that the user has access to.

Below is the current organizational structure. There is a business unit based on each territory. Security is set up so that users can only see and access data in their specific business unit, except for leads.

Let's say that a user in the Eastern BU creates a lead, but a contact already exists in the Midwest BU. Since the user doesn't have access to check against the records in the Midwest BU, this would allow the user to create the lead record. If the contact existed in the Eastern BU, the duplicate detection would have caught this duplicate record.

There are a few different ways to handle this situation:

  1. Allow users read rights to all leads, accounts and contacts. This might not be the best option as this is the reason you set up your CRM hierarchy.
  2. Create a new security role that has permission to the whole organization and grant one person this role. This user would then be required to create any new records that you want the duplicate detection turned on for.
  3. Create a duplicate detection job that is run by an administrator user that has organizational rights to the lead, account and contact entities. Any duplicate records would have to be merged by a user who has rights at the organization level.

The option you go with will depend on how your organization handles the way data is shared among its users.

If you need help developing best practices for your particular organization regarding security roles and duplicate detection, PowerObjects can help. Contact us for more information.

Happy CRM'ing!

Out of the Box Report: Dynamics CRM User Summary

One of the important tasks for Microsoft Dynamics CRM 2011 administrators is ensuring users have appropriate access to the system. One of the challenges of doing an efficient user audit is easily seeing a list of all the security roles each user belongs to. No worries! There is a report that allows you to conquer this challenge.

Microsoft Dynamics CRM 2011 has about 25 out-of-the-box reports. Most of the reports analyze your CRM data. However, there is one report for administrators: the Dynamics CRM User Summary report.

Let's take a look.

  1. In CRM, click on Workplace.
  2. Click on Reports.
  3. Double click on User Summary.
  4. The next screen allows you to filter the user list.
  5. Once you've set your filter criteria (you aren't required to filter your report), click on Run Report.
  6. The resulting report will display:
    1. Information about each User
    2. Users grouped by Business Unit
    3. A listing of all the security roles to which each User belongs

Dynamics CRM User Summary Report

Not only does the User Summary report give you a list of users, it allows you to see which security roles each user belongs to. The only other way to see if a user belongs to a specific security role is by accessing their user record. This can be time consuming especially for larger organizations. Another benefit is that you can access the User record directly from the report, making it easy to alter access levels. And it's just a great way to audit user access.

NOTE: This report does NOT show roles assigned to Teams.

That's all it takes!

Want to know more about security roles in Dynamics CRM? Take a look at this recent blog if you'd like to learn how to restrict how information can be taken out of your CRM system.

Happy CRM'ing!

A Tip for Dynamics CRM 2011 Security Roles

Many companies create silos within their data for security reasons. One way to do this is to increase Dynamics CRM security settings to make user-owned records read/write-only. This works, but it can also present some challenges.

For example, what if one of your sales reps approaches a client about some new products, without realizing that the sales rep two desks down has been in contact with the client about these opportunities for over a month? Now you have a flustered salesperson and an annoyed client.

Ideally we'd prevent this from happening by having all sales reps reference data in Dynamics CRM before approaching a client—but what the sales rep in our scenario doesn't have the security rights to see that information?

Luckily, there's a solution for this. We can create a new global entity that would have basic information about any entity—Accounts, Contacts, Opportunities, Leads, etc.—without revealing sensitive data. We would do this by creating a custom entity and running a workflow to copy over the data that isn't a "trade secret" (i.e., it can be found on Bing).

Let's walk through how to do this step-by-step.

  1. Go to settings on the bottom left corner of the page.

    CRM 2011 security roles tip

  2. Once in the settings page, go to Customizations on the site map to the left.
  3. Select "Customize the System."
    Note: In order to make these customizations, you must have the correct security role/setting. Talk to your system administrator before continuing!

  4. Once you are in the system, the "Components" button will show you almost everything in the system. You'll need to create a new entity. (It is recommended that you do not use the out of the box default of "new_" as the preface for your schema name. You can find more on that here.)
  5. Once you've created your custom entity, go to the out-of-the-box Accounts entity and expand the tab.
  6. From the expanded tab, select the fifth item down—the "1:N Relationship."
    (1:N means a one-to-many relationship. This means that there will be one Account record and the potential for multiple records to be associated to that Account record. For this situation, we're technically making a 1:1 or 1-to-1 relationship, but in terms of database language, relationships are either 1-to-many, many-to-1, or many-to-many.)
  7. We want to create a new 1:N Relationship and set it to your new custom entity as the related entity.
  8. In the example below, I created a custom entity called Global Accounts. This is where you'll set a parental relationship. We do this so that if the Account record is deleted or deactivated, the child records (e.g. the Global Accounts) will be deleted/deactivated as well as the "Type of Behavior" settings to Parental tells the system to cascade down to its children.
    It's basically a waterfall—if you pour food coloring at the top (the parent record), everything below (the child record) gets that food coloring as well.

  9. Now go into the form section of the Account entity and add in a field as a reference point for the system to look into. In this example, I called it allaccountlookup and make it a lookup field into my custom entity.

  10. Now we'll go back to the custom entity and add in fields that we want to be viewed by the organization, team or group. Go to the custom entity, open up the form and customize it by adding in fields of your choice. In this example, I selected basic information like Account Name, Account Number, Street, City, State, Zip/Postal Code, and Owner. This way other users can quickly see who owns the record and basic information about the account.

  11. Click the "Publish All Customizations" button in the top ribbon, because now we want to move on and create a workflow to fill in the records.
  12. Go back to your main page and create a new process. Set the process to a workflow and name it to whatever convention you want. In this example, I renamed the out-of-the-box "Accounts" to "My Accounts". I'm going to run this workflow every time a record is created, assigned, or when any of the fields are changed in the parent entity.

  13. Now create a Check Condition and have it look at the parent "My Accounts" record. Set it to lookup into the allaccountlookup field and check if it contains data. You'll see I have it set to update the record fields in the All Account.

  14. Now we can create a Conditional Branch and do the same lookup, but instead of the allaccountlookup field containing data, we'll check for it to not contain data.
  15. Add a clause to create the record in t custom entity "Global Account" and have the same fill in fields as the image to the top right.
  16. Then in My Account (The Out of the Box Account) entity and make an Update into it.
  17. Set the properties by clicking on the custom field made in My Account, allaccountlookup, and set the operator on the right to "Set to". Make sure your workflow is set from User to Organization or to the specifications you want and activate your process. Also, be sure to make this read-only. We want this workflow to not write, as this is meant to be a reference:

  18. We should also set up the relationship of the flow of data to be one-way from Account to Global Account. To do this, go to administration and select security roles. Go into each security role and make your custom entity Read for the organization but turn everything else off on it.

There you have it! Now you have a custom entity that is a nice reference for the entire organization.

Happy CRM'ing!

Change CRM Security Roles to Limit Information Getting Out of Your CRM

I recently posted a great blog called "A Tip for Dynamics CRM 2011 Security Roles." It covers how to keep your sales force in the "know" while locking down the Accounts to be seen only by the people that use them. Let's expand on that!

Your CRM data is valuable and sensitive. System administrators and company leaders need to know the different ways it can be taken out of your company or found on a laptop or mobile device. There are a few easy adjustments System Administrators can make to security roles to ensure sensitive information does not get mistreated.

WAIT! Before you go gallivanting into the wide world of CRM Security Roles, please consider the following best practices:

There are 4 security role settings that impact a user's ability to take information out of CRM.

The steps to do this are:

  1. Check what security role(s) the user you want to limit belongs to
  2. Copy that role
  3. Make changes to the copied role
  4. Add the user to the new role and remove the old role

Let's take a look.

Step 1: Check what security roles the user you want to limit belongs to

This can be done by opening the user's record OR by running the User Summary report. Let's take a look at the User Summary report.

  1. In CRM, click on Workplace | Reports
  2. Double click on the User Summary report
  3. Click on run report
  4. The resulting report shows you a list of all your users and all the security roles to which they belong
  5. If the user belongs to more than one role, you'll have to make sure to check all of the roles

Step 2: Copy the existing security role
the user belongs to (you must have the rights to do this)

  1. In CRM, Click on Settings | Administration | Security Roles
  2. In the list of roles, highlight the one you wish to copy
  3. Click on More Actions in the dropdown
  4. Select Copy Role
  5. Save it with a name that makes sense to you

Step 3: Change the security role

  1. Open the security role you just created
  2. Click on Business Management tab
  3. Scroll to the bottom of the page to Miscellaneous Privileges
    1. This area contains all the tasks a user can perform. Most of the items can be turned on or off by clicking them.
    2. A green circle means the user can perform the function, an empty one means they cannot.
    3. Click on the circles to change their values. (see the image below)
  4. Once you're satisfied with the changes, click on Save and Close

Dynamics CRM Security Roles

Step 4: Add the new security role and remove the old one

  1. Click on Settings | Administration | Users
  2. Select the user you want to update
  3. Click on Manage Roles in the Ribbon
  4. Check the new role and uncheck the old one
  5. Click on OK

That's all it takes! Happy secure CRM'ing!