Category Archives: Consulting

Designing the right Security Model for Dynamics CRM

security-model-01 Whatever you do, don’t end up like the Death Star architect when designing the CRM Security model.  Running with this analogy regarding a space-wizards movie in a galaxy far, far away, it’s important to avoid giving any pesky rebel user the equivalent of an open exhaust port into your CRM system.

Dynamics CRM is designed by default to be an open and collaborative system.  However, there is always a need to restrict access to certain kinds of data depending on the user hierarchy and/or role in any organization.  Luckily, CRM provides various security tools to get the job done; all you have to do is finalize the right mix of access and performance.

Avoid “security through obscurity”

A key theme when designing the CRM security model is to avoid the practice of security through obscurity.  A simple example of this would be to hide access to certain records in the Views, but not consider that users may have access to restricted records elsewhere, like in Advanced Find.  Users don’t need the Force to quickly discover loopholes in your model.

Always consider all the ramifications of adding customized access when addressing security needs that may fall outside of the default security configurations in Dynamics CRM.  If there are known limitations in your design, be sure to clearly communicate them to stakeholders and highlight them in your documentation.  Ideally, stakeholders may be open to adapting security requirements according to Dynamics CRM best practices.

Suss out all security requirements as early as possible

During the process of requirements gathering, it’s important that all security concerns should be surfaced and documented as early as possible in the SDLC.  It may also be helpful to finalize reporting needs early on, since it would generally require a workable security model to display the right data according to user needs.

Introducing any changes to the security design of Dynamics CRM in a later stage of the project can guarantee a huge impact your delivery plan and budget.  Avoid being a target for that managerial force choke!


Sample scenarios to help choose the right tool for your security model

As a rule of thumb, you can use the below scenarios to help determine the right security tool in CRM to use.

“I want our general users to have limited permissions to records, but give manager users more elevated permissions to the same records.”

Create separate Security Roles in CRM according to different user roles, which should help address this requirement.

“I want managers to view all the records owned by their direct employees, but not see records belonging to other managers and/or departments”

Luckily we have several options here.  Each has its pros and cons, but all are generally safe options to address this scenario.

  • A combination of Business Units and Security Roles can provide this setup.  If managers and their users belong to their own separate business units (e.g. separated by departments), then they can be configured to have business unit access to records.
  • security-model-03A new feature in CRM 2015 called Hierarchy can be used.  There are two type of hierarchy configurations available: Managerial, and Positional.  More documentation about this feature can be found here.  The right configuration will largely depend on the organization’s hierarchy setup and needs.  It’s important to note that hierarchy should be used in limited circumstances to prevent potential issues with performance, particularly systems with large userbases.
  • Last but not least, a combination of Business Units, Security Roles and Hierarchy may be what is needed to address more complex cases.

“I don’t want users to see CRM records originating from this specific region, unless they meet at least 4 of these 12 conditions, and it was generated on a Tuesday morning.”

This requirement isn’t very realistic, but it’s to provide an example where an organization believes that they must meet highly complex requirements about when users can and cannot access records.  It’s likely that the out-of-the-box CRM security tools cannot easily meet these types of expectations as-is without some tricky code.

It is best in this case to demonstrate best practices for the system, and suggest workable alternatives that can be in line with their business rules.  However, if the organization won’t budge on their complex security requirements, there are security options in CRM that I call “wildcards”.  They are wildcards because they can help address the most complex requirements, but may also introduce unexpected performance results.

  • In CRM it is possible to programmatically “share” a record with a user.  The Sharing functionality bypasses any security model by directly granting a user access to a specific record.  As many Dynamics CRM aficionados know, it is best to use this functionality very sparingly, since it may overtax the system and cause performance issues for users.  However tempting this dark side may be, you should only employ this functionality if it can be proved that system performance can scale according to usage.
  • A combination of Sharing and Teams may be an alternative strategy.  Teams allow us to group users and assign access in bulk.  Sharing a record to a Team record will be more efficient for the system than sharing the same record with multiple User records.  This approach will help minimize the impact to the system performance, but should always be fully vetted and tested for scalability.

Security Modeling Tools Matrix

To condense most of the content above, I’ve provided my analysis of the different security tools available in CRM.

Security Concept Description Implementation Details Best Practice Scenario Considerations
Business Units Business units are groups of users, typically associated in a parent-child structure. BU’s can be structured according to an organization’s regional or departmental model, depending on security needs. Use Business Units in combination with Security Roles to design the “classic” CRM security model. * Consider another security model if the organization needs to frequently modify the BU structure, as it also impacts Users and Security Role assignments.
* Creating more than a few dozen Business Units may not be tenable for system performance and maintenance in the long term.
Role-based security Security Roles can be configured to provide granular record access for a user to data. Always use Security Roles to grant read, write, create, delete, and other access to specific type of records. Use Security Roles in combination with Business Units to design the “classic” CRM security model. * Do not overwrite out-of-the-box Security Roles as you may need to fall back on them for testing purposes.
* Testing a user’s security role access is key to a successful implementation.
Record-based security You can use record-based security to control user and team rights to perform actions on individual records. A user or process may need to grant record access to another user/team that otherwise would not have access. This feature is typically a manual process for users to grant other parties ad-hoc access to their record(s).  In certain cases, the sharing of records can be programmatically implemented. * This feature should be used sparingly on a record-by-record basis, as it could potentially impact system performance and bypasses the security model in place.  It may be best to consider an alternate security model instead.
Team Security A user’s access to data may be determined according to their Team assignment. Teams let users across an organization collaborate and share information. Teams make sense in scenarios where users are granted additional permissions to records associated with the Team. * Determine whether a Team’s assigned Security Role will be the factor in determining the user’s access to records.
* “Access Teams” in CRM provide additional security options, but note that an Access Team cannot own records.
Hierarchy Security You can use the hierarchy security model for accessing hierarchical data. This additional security allows managers to access the records of their reports. Two options are available: Manager hierarchy and the Position hierarchy. Use of one over the other depends on the organizational structure. Best used in organizations where a BU/Security Role structure is not enough to address the need for a manager to access their employee’s records. * The impact that hierarchy has to system performance is dependent on the total number of users.  As a rule of thumb, use a hierarchy depth of 4 or less.
* With the Manager hierarchy, a manager must be within the same business unit as the report, or in the parent business unit of the report’s business unit, to have access to the report’s data. The Position hierarchy allows data access across Business Units.
Field-level Security Fields that contain sensitive information can be configured to have limited access according to the user’s role in the organization. Fields with sensitive information, such as Social Security Numbers or bank account information, should be strictly controlled and limited to certain parties. Record-level permissions are granted at the entity level, but you may have certain fields associated with an entity that contain data that is more sensitive than the other fields. * Testing a user’s access to personally identifiable information is key to a successful implementation, especially if there are HIPAA considerations.

security-model-04Designing a security model in CRM can be quite the puzzle to think about, but is an essential step towards a successful implementation of Dynamics CRM.  The challenge is coming up with a simple yet elegant design that can directly meet the organization’s needs.  If done right, you can be confident your CRM system can easily make that Kessel Run in 12 parsecs.

Wireframe Template for Dynamics CRM 2015, free to use. Now with Dashboards!

An update to this blog has been looong overdue.  In came the new year, along with a brand new Dynamics CRM version.  So, what better way to kick it off than to post an update to the Wireframe Template!

This new version has been updated for Dynamics CRM 2015.  More importantly, however, I’ve now added the ability to fashion a Dashboard wireframe. This was the most requested feature since the previous version I posted a year ago.

A short list of the new updates and features below.Visio-Professional_2015-02-08_21-15-48[1]Dashboards - Wireframe Template for CRM 2015

  • Updated top Nav Bar on all tabs to match Dynamics CRM 2015 appearance.
  • All files are now Visio 2010 compatible.
  • *NEW!* Dashboards tab
    • Click on the Dashboard tab to view.
    • Pie charts, Bar Graphs, and Line Graphs all leverage Visio functionality.
    • Edit the properties of the chart to configure according to your design.

To download and use this template:

  1. Download the ZIP file at this link.
  2. To extract, enter the password:
  3. Open the file labeled “CRM 2015 Wireframes template (Visio 2010)” in Visio or other compatible editor.
  4. Add the attached stencils as needed to aid your design.

Please let me know your feedback on this new version by adding a comment below.  Feel free to use it and make it your own, but I’d greatly appreciate a link back to this very post should you share it.  Enjoy! :-)

Dynamics CRM 2013 wireframe model template, free to use

Please see this post for the latest version of this wireframe template!

Almost every single project I’ve been on requires some proof-of-concept visuals to help win acceptance from the client. It also helps generate some excitement about the end results.  Of course, new implementations based on the latest 2013 version of Dynamics CRM are no exception.

So, as a consultant or analyst, what are your options? Some say you can simply build a quick model in a trial or development CRM system. However, I will argue that there are significant disadvantages to this approach.

  • Should the client want to make frequent or significant changes to the forms, it’ll take time to re-build each iteration.
  • Due to the messy nature of modeling in the CRM system, the solution cannot be used for production. Rebuilding a new, clean solution adhering to best practices is necessary.
  • Generating sample data to populate the custom forms can be a time sink.

My solution? I built a wireframe model template in Visio that allows anyone to model the system with greater flexibility.

The features of this template include:

  • A cover sheet
  • Custom entity form template
  • Custom entity form template (125% zoom for readability)
  • Quick Create form template
  • Entity Views template
  • Navigation Bar template
  • Stencil for CRM 2013 forms
  • Stencil for CRM 2013 Navigation Bar buttons

Some advantages to using this template:

  • The ability to actively work with the client and make instant changes during design sessions, thereby reducing the number of cycles needed to get approval.
  • Leverage the included custom stencils to drag-and-drop components to the form you are designing.
  • Modify any text on the template form to match your vision of the entity.
  • Add notes on the wireframes to visibly highlight key information.  Some possible examples:
    • Field properties
    • Option set values
    • JavaScript functionality
    • Integration notes
    • View filtering conditions
  • Use the Visio template to complement your documentation.

Now, if you decide to download and use this template by clicking on the link below, my only request is that you give me credit for my hard work by helping to spread the word via a link to this very post.  It would be much appreciated!

This contribution represents a thank you to the Dynamics CRM Community.  I got to where I am now because you shared your knowledge and contributions over the years. :-)

In the future, I may add some Dashboard wireframing options to this document.  Please let me know if it proves useful for you, and I look forward to your feedback!

-Christian Espinoza