Design Rules for Microsoft Dynamics CRM Online and Onpremise

And here are some ‘golden’ design rules for Microsoft Dynamics CRM 2013 and 2015

 

Design rules for security:

  • For Users
    • Assign as few as possible security roles (privileges) to a User
    • Assign the user only to teams if really needed
  • For Teams
    • Assign only security roles if needed
  • For security roles
    • Use not too much security roles per user or team for grant access to the records.
    • Privilege accumulation consumes performance.
      • Each role for the user and each team role in which the user is assigned will be computed to the individual user security mask
  • For field level security
    • Not more than 10 attributes for filed level security, (best practice for CRM 2013)
    • Use the ‘filed level security’ feature only if you need it.

 

Design rules for forms:

  • Use iFrames judiciously. The greater the number of iFrames on a form, the greater the associated form load time will be. For each iframe a blank.html site will be loaded.
  • Use sub-grids judiciously. Each sub-grid that is used in a form queries the Microsoft Dynamics CRM system in the background for a set of data to load into the grid.
  • Close all not needed sections.
    • HTML content and sub grid data will be loaded on section expand.
  • Include only the fields you need on the form. The greater the number of fields on a form, the greater the associated form load time will be.
  • Use role-based forms for different forms
    • Maintain the form order (the first main form is the mobile client form)
    • assign security roles
    • Deactivate or delete unused forms
  • Only for CRM 2011 — Load form elements iFrames and sub-grids asynchronous.
  • Only use auto complete on lookups if needed
  • Retrieve data asynchronous via SOAP or Odata request

 

 

 

Design rules for sahring:

  • Avoid so much shares as possible
  • Share records to teams not to users
    • 10 Records, shared to 10 users = 100 POA records without implicit shares
    • 10 Records, shared to 1 team with 10 users = 10 POA records without implicit shares
  • Remove shares if a record is inactive or ‘to old’
  • Use Access Teams
    • if the number of teams is dynamic and not known during design
      • This will typically happen if there isn’t a guiding factor for definition of teams (Territory/Product and so on)
  • Use System generated Access teams (Record teams) when the users that need access are unique across entity instances and so require one or more teams per record instance (for KAMs)
    • Note: More than one team is required if different access right is desired for the team’s members

 

Design rules for ownership:

  • For ownership
    • Business Units and Users
      • Use Business units when you can organize users based on access scope and the access requirements can be limited to records owned by themselves, records owned by other users in same unit.
      • Use Business units for isolating access between departments / regions
      • Use Business units for organizing hierarchical access to users in business units at the top of the organization.
      • This should not be used when hierarchical access causes explosion in number of business units.
  • or
    • Teams
      • Use Ownership teams when you need to provide access to a set of users across business units
      • Use Ownership teams for access when the number of teams is fixed and known apriori.
      • Is the best way for large organization with millions of record

 

Design rules for auditing:

  • Use the auditing feature only for entitles and fields you need it
  • Deactivate auditing while initial loads are running

 

Design rules for entity design:

  • Think before customize.
  • Relationship between entities
    • Use Cascading / Parental only if you need it
    • Have a look at the system entity relationships (for example: account to account relationship)
  • Create only field you need
  • Use the Reading pane in CRM for Outlook only if you need it

 

Design rules for CRM for Outlook offline:

  • Offline Data Rules
    • Only sync data which you really needed
      • No historical data
      • No inactive records
      • Not all organization owned data like product
    • Don’t use the ‘parent is downloaded’ feature, this decrease the sync performance.
    • Use background sync for speed up the ‘go offline’ process
  • All application test must be done at the offline client too.

 

Design rules for views:

  • Limit search columns in the quick find view
    • Set an index for all search columns, sometimes use filtered indexes
  • Limit the columns in the views
  • Make no lookups to other entities

,

No comments yet.

Leave a Reply