EXAM MB2-703 – Customising CRM 2013 : NOTES
Kevin Crampton – 28th Feb 2014
http://www.microsoft.com/learning/en-us/exam.aspx?ID=mb2-703
Replaces the earlier CRM 2011 MB2-866 customising exam.
Concentrates on the aspects of customizing that are new in CRM 2013.
Resources: Microsoft course 80542A and new Customising section of the implementation guide.
CHAPTER 1: INTRODUCTION
The course concentrates on the “point and click” customisations of CRM, not the code-writing which is
part of the Extending course.
There is a NEW Customization guide within the CRM 2013 implementation guide.
Overview of solutions and the concept of managed/unmanaged. Solutions help us package, help with
source control and versioning, help in collaborative environments. The default solution can only be
exported UNMANAGED and you cannot import an on-premises default solution to online or vice versa.
You can use the version number of a solution W.X.Y.Z for major, minor numbers or for year, month,
date, time – whatever versioning is meaningful for your project.
Use different publishers to separate different developers or suppliers – since this code is appended to
schema name it will keep same name entities separate. The publisher prefix can be up to 8 characters.
A managed solution can only be updated by a solution package from the same publisher.
Creating a publisher also sets an Option Value Prefix to ensure that values in option sets do not conflict.
When we create and work with a solution in our CRM it is always unmanaged, it only becomes managed
when we export it.
UNMANAGED SOLUTIONS ONLY STORE POINTERS TO THE ACTUAL OBJECTS MODIFIED IN THE SYSTEM
– not the objects themselves which is why deleting an unmanaged solution means that the changes
remain. This also means that if two developers are working on the same entity at the same time in two
different solution files they will see one another’s changes and have to collaborate closely to decide
when they publish.
This ultimately means that the solution file itself is not a good indication of what the original developer
was trying to change – only the entities that he was working with! For example Kev adds a field
Kev_Field1 to Contact entity in Solution 1 and Aurélia adds Aur_Field2 in Solution 2 then Solution 1 & 2
will both now show Kev_Field1 and Aur_Field2. Microsoft recommends using different publisher
prefixes for developers to make it easier to identify which developer was intending which change.
The Kev/Aurélia scenario above is particularly acute if we deploy an unmanaged solution to a production
system – looking at the solution alone will NOT tell us the changes it imported… it will show us the
changes it imported AND any other customisations/system fields on entities that the solution contains.
If two solutions contain changes to exactly the same component then the last one imported wins.
If you deploy a solution with a field and then deploy an updated version of that same solution without
the field, the field will remain in the target system – you can’t use solutions to remove fields in this way.
You can remove something from a solution (the pointer to it is removed but the item remains in the
default solution) or you can try to DELETE something in a solution which will attempt to erase it
completely from CRM. You can’t delete system entities of course.
MANAGED SOLUTIONS DO KEEP THEIR CHANGES APART and do not modify the base default solution,
so these are NOT pointers to items in the default solution. This is why you can uninstall them to
completely remove their changes. The application has the job of incorporating their changes with the
base solution to present the final system configuration.
Users, teams, access teams, business units, queues, goals, subject hierarchy and product data can’t be
added to a solution as these are all considered data. If you need these, deploy the data with the Import
Data Wizard.
You cannot import solutions from LATER versions of CRM into earlier version i.e. attempting to pull a
V6.1.0.0 created solution into a CRM instance at version V6.0.0.899. Only the first two numbers (major
and minor version are relevant). In future this approach MAY be possible using a process known as
DOWN-LEVELLING where CRM will remove features at the time of solution export because it knows that
these are not available in the earlier, target CRM system.
You can publish all changes relating to one or more entities or other components by clicking on that
node in your solution file. You can only publish everything linked to a single entity together – you can’t
just publish a view or form, it will publish everything related to that entity (forms, view, charts, fields).
Publish All Customizations publishes everything related to ALL solution files in the CRM!
When you create a component or sub-component it is published when you first save it (Page 1-18 of
Document 01 – this sounds wrong to me but I imagine they mean customizing roles although then
mention activity entities?!) so special care is needed as users will potentially see it before you are ready
to perform your final publish. Save As is also considered a first save as you are creating something new.
Custom activities are singled out for special mention as something to be careful of in this area.
CRM will show us the dependent and required dependencies – useful is we are trying to delete
something or if we want to know what must exist in the target system for our customisations to work
correctly.
CHAPTER 2: SECURITY
Hierarchy of business units to which users, teams and records belong. The root business unit is installed
when CRM is set up and can only be renamed, not deleted, disabled or given a parent.
Set up business units to model the data access and reporting needs, NOT copy the organization
organigram of departments.
When you disable a business unit all users belonging to it no longer have CRM access. All child business
units are ALSO disabled. The users themselves are not disabled, this is a separate bit of functionality.
Data linked to a disabled business unit it not lost.
To delete a business unit you must first disable it and then remove all users, teams and child business
units. Deletion is irreversible.
Facility/Equipment and Resource records will get deleted with a business unit so you need to move
those too if you want to keep them.
When we define a role in a business unit it gets copied to all child business units – called inherited roles.
You can’t change these child copies – only the original one.
In a solution package you can only create roles in the ROOT business unit and rely on this inheritance for
them to appear everywhere else.
Inheritance is good because users and teams can only be assigned to roles in their own business unit and
so inheritance stops you having to duplicate roles all over the place.
Microsoft recommends creating all security roles in the ROOT business unit if possible and creating
copies of the “out of the box” roles to retain the default ones as reference.
You cannot modify the System Administrator role and at least one enabled user must have this role at
any one time.
Roles cannot be moved from one business unit to another.
CHAPTER 3: CUSTOMISING ENTITIES
CRM comprises system and custom entities. More than 90 of the system entities can be further
customized to extend and adapt them. Certain system entities CANNOT be customized as they are part
of the core framework of CRM such as the entity system job.
Anything that can be customized in CRM is called a customizable entity – so this includes system and
custom entities. The difference between customisable and custom entities is that all custom entities
can be deleted but since customizable entities includes system entities, you won’t necessarily be able to
delete these.
Certain system fields will get created when you set up a custom entity and you won’t be able to delete
these.
You can specify that custom entities are owned either by user/team or by an organization. User/team
ownership means that the entity behaves like normal and the five-level access permissions based on the
business unit structure can be defined. Entities owned by an organization do not participate in this
security and you must grant all/none permissions to access the entity globally – there is no link with
business unit and they cannot be assigned, shared etc. A product might be a good example of an
organization-owned entity.
The other big decision is creating your entity as an activity. If so it appears with the usual activities in
CRM and has certain key fields by default (planned/actual start and end dates for example). In fact
activities are defined in CRM by a link to the Activity Pointer entity so that CRM is able to display
different types of activities together. When creating a custom activity entity you can specify that it
should not appear in “Activity Menus” so that it cannot be created directly like other activities.
Be default, a custom entity will only be available to the System Administrator and System customizer
roles. You must assign the extra roles to ensure other users can access and use it. Note that activitytype custom entities are governed by the same roles as other activities so that users will get the same
permissions for your custom entity
CRM 2013 adds the concept of the primary image for entities. 24 system entities also are set up with
the image capability. When turned on the image appears at the top of the entity form. When you turn
images on you select the name of the field used to store the image in the entity. This is either “Default
Image” for system entities or the field name for custom entities. In fact the process for creating it is to
create your entity with a primary image of NONE, save it and then create a field of type “entityimage” –
the entity then automatically gets set to use that image.
Custom entities must have a PRIMARY FIELD defined. This is the name of the entity and depending on
whether you are creating an activity custom entity or a non-activity custom entity there will be certain
restrictions on how you set the primary field up. It must always be a single line of text.
The primary field is used for lookup lists and for hyperlinks to the records.
Do not use the entity name as the field name as this combination is used by the GUID ID of the record,
for example – I create entity KevEntity – the GUID ID will have schema name new_KevEntityID and
display name new_KevEntity so I should call my primary field new_name or something similar and NOT
new_KevEntity!
Note that when creating a custom entity you set up the tick boxes to display which navigation menus of
the CRM you want to display the custom entity in. This information is written to the site map when you
save the custom entity. This means that you must include the site map in a solution package if you want
to deploy those changes, deploying the entity alone is NOT enough.
When setting up a custom entity you also specify whether it will be enabled for business process flows.
This cannot be deactivated once activated as CRM creates a set of fields in the database for it.
You can turn on notes, activities, queues, access teams, SharePoint integration, email sending field etc.
for an entity using a set of tick boxes. Notes, Activities, Connections, Email, Queues and Business
Process Flows cannot be disabled once enabled. I repeat this at the end of the chapter notes as I
suspect that there will be at least one question on it!
You can specify whether an entity has a quick create form enabled. Note however that if it is a custom
ACTIVITY entity then the quick create form is used for sub-grids and look ups, the global “Create” button
at the top-right of the page still uses the usual form, not the quick-create one.
The course notes went in to some detail about what properties could and could not be modified on an
entity after it was created.
A new CRM 2013 feature is the ability to specify whether an entity is available for phone and tablet
interaction. You can specify that the entity is read only on tablets. You can also specify how the entity is
used in Outlook – whether it has a preview window and can go offline.
Renaming an entity after it has been created is difficult, not only do you change the name and plural
name but you need to track down all views, reports, labels and messages that use the old name and
manually change those too. Or use the Export Translations tool to hunt down the old references.
When a custom entity is deleted it is removed forever so often better to modify security rules to hide it
rather than do a “hard” delete! An entity must have no dependencies for you to be able to delete it.
THINGS THAT CANNOT BE CHANGED AFTER SAVING A CUSTOM ENTITY THE FIRST TIME: 



The schema name
Ownership (User or Team or Organisation)
Whether it is defined as an activity entity.
Whether it is shown in Activity menus.
THINGS THAT CANNOT BE CHANGED AFTER THEY ARE ENABLED FOR AN ENTITY: -






Notes
Activities
Connections
Sending Email
Queues
Business Process Flow
NACEQB!
CHAPTER 4: CUSTOMISING FIELDS
Adding a field adds one or more fields to the underlying SQL database. The type of the field will specify
how many bytes the underlying data takes up in SQL Server. In CRM 2011 and before the SQL database
used 2 tables per entity (the base fields and the extended custom set) but in CRM 2013 this has been
merged together in to one table. This information is hidden away behind views however and so working
against views and NOT tables continues to be the recommended approach.
Be wary of adding hundreds of fields – there may be constraints in the underlying SQL table definition.
The single line of text field now supports email, url, ticker symbol and phone text – depending on what
you choose CRM will render the data as a link that opens the email client, the browser, a stock quote or
Lync.
Remember that IME is Input Method Editor for entering a sequence of characters to generate a
Japenese, Chinese or Korean symbol. IME mode can be set as inactive or disabled.
Option sets (local and global) work as they did in CRM 2011. Set the prefix for the publisher to avoid
overlapping values. The default solution starts with option set value 10,000.
The two value option set stores its data in the CRM database efficiently as a 0 or 1. Two value option
sets must provide two values (Yes, No / Male, Female) – null is not a valid option, for this reason you
can’t really use mandatory (business required) logic on such a field as by default it will always have the
first value. If you do want such mandatory checking behavior then use a normal option set with three
values – unassigned, value 1 and value 2 and set the default to “unassigned”. Two-option sets can
display as radio buttons (not rendered as radio buttons, instead the whole label becomes a toggle),
check box or list. In a view a two-option set is always shown as text (not checkbox for example).
The whole number field type can be used for integers and also for duration (it stores the number of
minutes), a look up list of timezones or languages (only languages installed on CRM are shown). For the
duration the CRM will understand input such as 1.5 days or 2.25 hours. Whole numbers can range
between + and - 2,147,483,648. Best to set a realistic min and max however for validation.
Floating points numbers can store from minus to plus 100,000 million and up to 5 figure precision
beyond the decimal point. They are inexact however and can lead to rounding errors. This is because
SQL Server serves a very close approximation to the number in the database as binary.
Decimal Numbers are exact and not subject to rounding but take up more space. They can also range
from minus to plus 100,000 million with a precision up to 10.
Type
Whole Number
Floating Point Number
Decimal Number
Range
+ / - 2,147,483,648
+ / - 100,000 million
+ / - 100,000 million
Precision
0
5
10
Use decimals when you need higher accuracy or small issues could compound in aggregations. Also use
decimals if you are likely to search for data with inequalities. Also be aware of integration
considerations – if you are importing data as floating point type from another system then keeping it as
that in CRM will avoid the need for an automatic reconversion to, say, decimal.
Currency fields are modelled as four fields in the underlying database – the value entered by the user, a
lookup to the currency of entry, the exchange rate to the base currency and the value in the base
currency of CRM. Adding additional currency fields adds only TWO more fields as the currency lookup
and exchange rate are already present!
By default currency fields use the Currency Precision set for the organization (this is set up in the
Currency section of Settings). Or you can override this with your own value or choose to use the Pricing
Decimal Precision, also a setting at the organization level in the Administration/System Settings section
of settings.
Multiple lines of text is used for storage of large text – it takes up 2 * n (number of characters) and the
maximum length is 1,048,576.
Date & Time can store either Date or Date & Time (a datetime is used in SQL Server) and is UTC enabled
so that the time is entered for the current user’s time zone.
Lookup fields are used for 1:N relationship look up. MSFT recommends that you create the relationship
first and then the field rather than trying to do all at once by just creating the field.
Image fields are new for CRM 2013 – 24 system entities support these for which 8 are enabled by
default.
Images always use the schema name entityimage – this can’t be changed and ensures that there is only
one image per entity. Images are rendered as a placeholder icon at the top of entity forms and the user
clicks on this to upload an image in a variety of supported formats and under 5120KB. All images are
stored as 144 * 144 pixel JPGs in a special dedicated SQL table so that entityimage is effectively a
lookup.
For all fields CRM allows you to enter a Display Name (label on form, column header in view, name in
advanced queries) and Name (column name in SQL Server). Name cannot be changed once created.
Requirement level for a field can be Optional, Business Recommended or Business Required but this is
ONLY applied on forms. If data is brought in via the SDK, PlugIns, Workflows or the import wizard, these
settings are ignored. Business Required fields cannot be removed from forms.
You can set Searchable to No to ensure that certain fields are never shown in Advanced Find.
Field Security is turned on at the field level if you have particularly sensitive data to protect. Field
Security must be associated with a Field Security Profile (more later!)
In CRM 2013, the Description provided for a field now becomes a hover-over or tap (on touch devices)
tool tip about that field. If it is not set then the field label is just display instead.
You can edit the properties of multiple fields at the same time, any values not specified will be left
unchanged.
Option Sets can be defined on an entity or global to the organization. Translations for different
languages can be provided. If a global option set is used, then each time it is placed on a form you can
select a different default value to suit your needs. Option Sets are stored as an integer in SQL Server.
Global option sets are generally the better option as they can be deployed separately (entity option sets
require that the entity be deployed), they take less effort to maintain and if you wish to copy the value
between fields using a workflow or plug ins then you are always confident that the list of options is the
same in the two so that an error won’t occur. Likewise if you set up a relationship with field mappings
(more later) so that data is copied from parent to child then global option sets also ensure consistency.
Local option sets are a good choice if you want to limit the scope of the field. If we need to change it for
instance then we only need to talk to the team responsible for that entity, not consider the effect on the
wider system.
Removing an option from an option set needs careful consideration as the integer value in the
underlying database is not removed and so will still show up in “Contains Data” queries. If the option
set has a default value then next time the user visits the form the record will be reset to that.
MSFT recommended approach therefore is to do an advanced find to detect and reset the unwanted
value and or change the text to “Do Not Use” and then use a business rule or workflow to detect
selecting it and prevent the record being saved!
A better approach for options sets that may change is to create a new custom entity and a look up on
this. We can control the security better and we can make a whole record inactive in this scenario so
that no data is lost but it cannot be chosen in future.
Every record has a STATUS and STATUS REASON. Status is Active/Inactive and Status Reason gives us
more information (if necessary) why the status is what it is i.e. status inactive for a phone call and status
reason Call Cancelled. Status is statuscode in the schema and status reason is statecode. For new
custom entities, the Status Reason is active/inactive by default and just mirrors the information in the
Status field. You can modify Status Reason like any other local option set. You cannot modify the Status
Reason on certain system entities where the logic associated with this state is intrinsic in CRM – such as
a phone call’s status reasons.
Before changing an entity you should look at “show dependencies” in the Solution file. Note that
Reports and JavaScript are not searched to find dependencies however and so this functionality is no
substitute for thorough documentation. Developers can explicitly specify a dependency when deploying
JavaScript to a form.
Reports and JavaScript will throw errors if they refer to fields that have been removed.
CHAPTER 5: RELATIONSHIPS
1:N relationship from a parent to zero or more children. Maintained as a look up on the “child” form
that stores the GUID of the parent. Note that the lookup field is not automatically added to the child
form, you must add it yourself. You set a Name and Display Name for the lookup field just like any
custom field.
N:1 is the same as a 1:N – it is just created from the child entity first. In the underlying database a 1:N is
created.
CRM suggests the name publisher_displaynameid for the name of the lookup field created for 1:N but
MSFT recommends that you change this to publisher_primaryentityid to make it clear that this is a look
up field pointing to the GUID of the primary record e.g. on a booking form : kev_contactid – the contact
that made the booking. When setting up a 1:n relationship you can define the default display on forms
– what section of the form it appears in, whether the plural name (Bookings) or a custom text is used for
the label.
You can also create a 1:N relationship by directly creating a look up field in the field or form designer but
then default values are used for the other relationships settings and you need to repass the relationship
property page to set these.
N:N relationships such as between students and training courses. Two ways to create these – “native”
using CRM built-in functionality or manually create a custom entity as your intermediate linking table –
which is particularly useful if you need to add extra fields specific to the relationship. The intermediate
table used in a N:N link is called the intersect entity, link entity or link table.
The native approach creates an intersect table automatically but it is hidden from you and so cannot be
further customized or used in queries or workflows. This native intersect contains a GUID, the lookup to
record 1 and the lookup to record 2 – this means you could find all courses attended by students but not
when that link was created. The Append and Append To priviledges are used to control whether a user
can create the link – they need append and append to privilege on both record types participating in the
link. Auditing is always enabled for N:N relationships.
The manual N:N approach is good in that you can now add extra columns or query the custom entity
direct but the disadvantage is that you will not get out of the box grids on your entity forms showing the
related entity in the N:N – you will only see the intermediate entity. For example, for students and
courses, if we create an intermediate manual custom entity “booking” we will now have a grid of
bookings on the student form and a grid of bookings on the courses form but NOT a grid of courses on
the students form or students on the courses form! Extra work would be needed to achieve this – for
example creating a custom view and placing that on the form.
A few system entities use manual N:N relationships that you can query such as queue items or user
“follows”.
You can configure the CASCADING behavior for 1:N relationships – how a change to the parent affects
the linked children. The two mains types are PARENTAL (what happens to the parent cascades to the
child) and REFERENTIAL (no cascade, the link is a reference only).
An entity can only have one N:1 PARENTAL relationship with another entity, it is the “belonging”
relationship and all other relationships must be referential.
If you are creating relationships between system and custom entities then a few restrictions apply: Type
1:N
1:N
Entities
System Primary to Custom Child
System Primary to System Child
1:N
1:N
Custom Primary to System Child
Custom Primary to Custom Child
1:N
Custom Primary to Activity/Note
Child
Comment
Referential or Parental
Can be Referential or Parental but because you can
only have one parental relationship and many
system entities already have lots of relationships this
is likely to be a referential relationship.
Referential ONLY
Referential or Parental but as ever only one
relationship can be parental.
If you select to Activity-enable a custom entity then
this relationship is automatically created for you.
Likewise if you create a new custom activity entity
then N:1 relationships are automatically calculated
for all entities that are currently activity-enabled.
You can define cascading behavior for all the key operations that can occur to a parent; assign, share,
unshare, delete and reparent (of the related entity, not the primary one). The interface also shows the
merge action but since this action is unavoidable you can never actually configure it and it always
appears as greyed out.
The cascade options are Cascade All, Cascade Active, Cascade User Owned, Cascade None. For
example when the primary entities sharing is changed then a cascade all would ensure that all related
entities are also shared. Cascade active only changes the active entities and cascade user owned only
changes the entities owned by the same user as the primary entity. If any entities are owned by an
organization then Cascade User Owned cannot be used.
Deletion is a bit special, there the options are Cascase All, Remove Link, Restrict – either delete all
related entities, break the link so that the look-up field on the child is blank or STOP the deletion being
performed if there are related entities.
Cascading rules OVERRIDE security rules so they can be a way for a user to perform an action that they
are not usually allowed to do. Careful thought is needed here as the cascade might even delete records
that the user can’t actually see because of their security role configuration.
You don’t have to provide the cascading rules for each of the actions because CRM provides a pre-built
set of template rules which are the most common configurations: -
If you set any rules to Cascade All, Cascade Active or Cascade User then CRM considers this a parental
relationship and will block the change with an error message if a parental relationship already exists
for that entity.
In one of the questions it talked about setting a new project custom entity and linking cases to the
project. The requirement is to reassign the cases when the project is reassigned – this would require a
CASCADE ALL on the Reassign operation and because Cascade All is a parental relationship and custom
entities CANNOT be the primary entity in a parental relationship to a system entity (the note in red on
the previous page), this would not be allowed. You’d have to write a plug in to do the change for you.
MSFT recommends careful consideration of how you cascade Assign rules to ensure that you don’t
inadvertently re-assign records. Likewise cascading Shares could lead to a lot of records being shared
and negatively affect performance. Remember that there is a “Share records with original owner”
option in the System set-up that can be used to ensure that the original user still has access to the
record (this option is turned off by default). MSFT also recommends configuring the unshared cascade
the same way as the share to ensure that sharing can be removed by the reverse process.
MSFT recommend reviewing the cascading rules for the main system entities for a new deployment to
ensure that unnecessary cascading is not occurring.
Reparent is different to the other rules because it is triggered by a change to the related entity, not the
parent. When you reparent, the owner of the primary record is given a share to the records related to
the reparented record to ensure that they can access them. This is called an implicit share and implicit
shares can live alongside explicit shares (even for the same user and record) in CRM and are maintained
in the same SQL table. This is native CRM functionality and is designed to ensure that the owner of the
parent record can view everything related to the reparented record.
EXAMPLE: An opportunity is created under the wrong account. It is reparented to reassign it to the
correct account – at this point the cascading rule implicitly shares everything related to that opportunity
(activities, notes, posts) to ensure that the owner of the correct account can see them.
An implicit share grants the owner of the primary record the same rights to the related records that
he/she has on entities of that type that he owns for example… We reparent a booking to a new contact.
The owner of the contact record now has an implicit share for the repareneted booking record and its
related activities, notes etc. with the same level of access as if he had created a booking record himself.
Security roles always limit the access rights that the user has to a record via an implicit or explicit share.
If we get an implicit share to a booking record and we can only read booking records then that read-only
access will be enforced.
The reparent rule is NOT triggered by a change of ownership – it is triggered by setting a new record via
the one and only parental relationship, if it exists.
Also note that if we reparent a record and give it to a new parent that is owned by the same user or
team as the original parent then CRM does not create an implicit share – there is no need as the original
owner has access anyway.
Use the Delete cascading rules to prevent orphans or to prevent a primary record being removed if it
has dependents.
Field Mapping rules can be set up in relationships to ensure that when a related, dependent record is
created, data from the primary parent is copied in to form a default set (that can then be changed). For
example copying a company address down to the contact records that belong to that company. Field
Mapping only works if you start at the primary record and opt to create a new dependent record from
here, it does not work for instance if you create the new dependent record from scratch and then set its
parent with the look up field. Mapping only occurs one-time on creation – there is no auto rule for
cascading changes from parent to related record after creation.
You can map source fields to one or more target fields. There is also a tool for automapping fields based
on data type and schema name (not display name).
To make a map between two fields they must be of the same data type and text field length cannot be
shorter for the source field than the target field. For numeric fields the range of values must be the
same.
Since option sets map their numeric values, using global option sets is the best choice as mapping
between two local entity option sets might cause issues if their lists are not the same; values present in
the source and not the target will be discarded and if 2 maps to “Kevin” in the source and “Aurelia” in
the target then that value will be set as Aurelia when mapped.
Remember that in addition to relationships, CRM also has connections allowing you to link any two
records that are enabled for connections. CRM stores a number of roles in the Connection Role entity to
describe the relationship between the entities. The same two records can be connected multiple times
with different roles – or the same role it seems 
You can link records to yourself to have a quick way to build up a portfolio of records that you are
interested in. Be careful however as the My Connections view shows the actual entities (not the
connections) and so deleting a record here removes the actual data, it does not break the connection.
Connections are used to power the StakeHolder grid in a Contact and Related Cases for a Case.
You set up what entities a connection role is valid for and you can set up matching roles to define the
options for the other end of the connection e.g. if I select “Mother” as a connection role then if I have
configured CRM with matching roles of “Son” and “Daughter” these will be used to limit display.
Matching roles are optional as not all roles have an obvious counterpart.
Connection Roles also have a category “Family”, “Business” etc.
To create a connection a user requires the read and append to privileges for both entities involved.
CHAPTER 6: FORMS
CRM 2013 uses a responsive display that changes the layout of forms depending on the screen size
available.
Entities have at least one main and one mobile form. The mobile form is for phone clients and the main
is for the web, tablets and Outlook.
29 entities have been updated in CRM 2013 to use the new form style which also means that they can
use the new Business Process Flows and Business Rules. Other entities remain on the “classic” forms
with the ribbon bar and left-hand navigation. These cannot use business process flows or rules. The
same form editor is used and disables any features not available for that form type or entity.
Note that when upgrading from CRM 2011, the new forms might get installed alongside the old classic
ones so you can control when to activate them. There is also a merge tool to help bring changes from
the old forms in to the new ones.
Forms are structured in to tabs (summary, details etc.) with columns and sections. Tabs can use up to a
three column layout for the web. If the CRM is being viewed on a smaller display then the columns will
be arranged vertically not side-by-side. For tablet display they are always side-by-side with scrolling
horizontally.
We can have up to THREE columns in a tab and a section within a column can have up to FOUR columns
side-by-side. The screenshot is an example of a three column layout in a tab with a four-column section.
Section columns always evenly divide the tab column width available to them. Items we place in the
section can span columns however.
You can only set the width percentages for the TAB columns, NOT section columns.
MSFT recommends using TABS for multiple columns rather than sections as the responsive design will
reorganize tab columns to fit the width available for display but section columns will always be rendered
side-by-side.
You cannot remove a field that is business required or recommended, has been locked or has script or
non-script dependencies associated with the field – a red padlock is shown in the form editor to indicate
these fields.
Forms can be given a max width (default 1900 pixels) to ensure that they don’t expand beyond a certain
size.
Parameters can be set up on forms so that if opened by code, data can be passed to perform some key
actions - set up default information on the form for example.
A dependent section of form properties lets you specify any dependencies between fields and code and
other elements (IFrames, HTML web resources etc.) to ensure that you do not accidentally remove a
field that is relied upon.
Field editing is the same as CRM 2011 but CRM 2013 introduces the concept of a composite field in
which multiple elements are shown in a small flyout window (Full Name decomposes to First Name and
Last Name for example). You can’t change their behavior or add new ones, only use them on forms. If
one or more fields in a composite field is set as business required or recommended then the composite
field is displayed with this level.
Sub-grids on a form show related records from a view. They can display their data as a chart or a grid.
You can opt to include a Search Box and a View Selector. If selected then the Label is shown by default
but is actually rendered as an info-box when hovering over the top of the grid. You can decide whether
to display no view selector, all views or just some selected views.
You can also opt to display the “index” – the A – Z for quick filtering. This is not supported in the newstyle CRM 2013 forms and so will have no effect if enabled.
The Notes control is new for CRM 2013 and shows the Notes, Activities and Posts in a single three-tab
display. MSFT recommend calling this the “social pane” to end users as it is referred to as NotesControl
and Notes in the implementation. You can only add the Notes control to a form once.
Quick View forms are added in CRM 2013 to provide a read-only quick view of the parent record related
to the current record – such as the account to which a contact belongs.
Because of the system traffic they cause, MSFT recommends adding IFrames and HTML Web Resources
to tabs that are collapsed by default so that they are only activated if necessary. You can use JavaScript
code on the tab expand state to set any parameters passed to the web resources.
Bing Maps can only be added to system entities that have a composite address field (Account, Contact,
Lead, User, Quote, Order, Invoice, Competitor). For online users the subscription is included in their
cost. For on-premises deployments a Bing Maps API key must be requested. There might be an
additional charge for this service.
The left-hand of the form editor allows us to set up form navigation to related
entities. However the five sections that appear here cannot be deleted and
no new sections can be added!
Empty sections are not displayed however.
These sections can be renamed however.
Quick Create forms are introduced in CRM 2013 to provide a quick means of first creating a record when
the user is likely to have less information about the record and not be interested in sub-grids or related
records. Quick Create forms are fixed at 3 tabs of 1 column each and can only contain FIELDS and
SPACERS.
Multiple quick create forms can be defined for an entity but the user cannot chose which one they use!
The first one in the form order is the active one. MSFT built it this way to ensure that multiple imported
solutions containing quick create forms would not conflict with one another.
Four ways to access Quick Create forms; from the global “Create” button in the navigation, from the
“Add” button on sub-grids, from the bottom of Look Up fields and in the Associated View – Add New
<Entity> option.
You cannot assign security roles to control Quick Create form access!
If you use the Quick Create from a sub-grid or Associated View then it will be a child of the current
record and any field mappings will be applied and fields in the Quick Create form populated.
One exception to this rule, “quick” creation of system activities uses the normal form.
Quick Creation is turned on, on an entity by entity basis.
Quick View forms are used for display of the parent entity in a child entity. They can only contain fields,
spacers and sub-grids and are rendered read-only on the child form.
You cannot assign security roles to control Quick View form access!
When multiple “normal” forms are configured, they can be assigned to security roles and given a form
order. The first form that the user’s role gives them access to is the default one for web and Outlook
client. They can use the drop down to swap to others and that choice is then remembered until they log
out. On the tablet client only the first form is displayed with no option to change.
You can specify forms as “fallback” forms and the one which is highest on the form order list is
displayed if the security role settings inadvertently give the user access to NO forms!
Note that it is a valid approach to create a security role that grants NO access to entities but is used JUST
for giving access to forms. If you do this you need a naming convention to make it clear that this is how
the role is used and it’s probably better to assign the role to a team rather than laboriously do it for each
user.
Note also that you can block a form by making it inactive – quicker than playing with security. You can
deploy a solution with an inactive form to turn that form off in the target system. This is better than
deleting the form which would just remove it from the solution and then force you to delete it manually
in the target system.
CRM 2013 introduces Windows 8 “apps” for tablets and smart phone clients – a full list of supported
devices is in the Implementation Guide. When configuring entities you can select whether they are
exposed to Microsoft Outlook client and to tablets.
TABLET
A number of system entities are already enabled for tablet use. Certain are read-only (Case, Email,
Product, User, Team, Currency) and cannot be modified to be read-write. These may be writable in
future versions.
The apps participates in full CRM security so even if you have elected to show an entity on the tablets, it
might not appear if the current user’s security roles do not grant access.
On the tablet only the highest form in the form order is shown and there are some additional limits –
only the first 5 tabs or 75 fields are shown, hidden fields count towards this limit. No more than 10 subgrids can be shown, entity images are not shown on the form and web resources such as Bing Maps,
IFrames, HTML resources, SharePoint Libraries are NOT shown.
The tablet form is the SAME as the Outlook and web forms just rendered differently and with the
limits above.
SMARTPHONE
Forms designated as “mobile” are used for mobile phone use. These forms are used for both the CRM
Phone application and the phone’s web browser (/m is appended to the CRM URL), if the user is not
using the app.
A one column layout is used which is read-only be default with an edit button at the bottom. Only fields
with data are shown and the extra fields become available when you click on “Edit”. Users cannot
switch forms on the mobile client either.
CHAPTER 7: BUSINESS RULES
Business Rules are a new feature of CRM 2013 and can be used to apply basic business logic such as
making fields available, read-only, display an error message etc. They can be configures to apply to all
main web and mobile forms or just one specific main web or mobile form. This is called the business
rules’ scope. If you want to apply to more than one form (but not all) you must use “Save As” and copy
the rule several times.
Note that, the quick create forms is NOT an option – if you want business rules to apply to this then
you need to apply the rule to ALL forms.
You can only modify a business rule while it is in draft mode.
Error messages displayed by business rules will prevent the user from saving the form until the issue is
resolved.
Business Rules are defined once and then applied in the browser, on the tablet app and the phone app –
they are often called portable business logic as a result.
Business Rules are applied as client-side logic that is executed when their form is loaded or a field value
changed. They are not applied on form save. They are also not applied if the field is NOT displayed on
the form (they just do nothing rather than generate an error) – for this reason it is good to note the
business rule field dependency in the “non-event dependencies” properties of the form to flag that the
field is used by a business rule. Otherwise a developer might remove a field without realizing that the
business rule is using it.
When you first create a business rule it is in “draft” mode. You can test it by using the preview form
function which displays the form with all “active” and “draft” business rules turned on.
Business Rules are ACTIVATED using a button on the command bar. You must first deactivate a business
rule if you want to delete it. You must save a business rule at least once before you can activate it.
After that you only need to “save” if you change the name.
Business Rule combine their conditions in a logical AND nature. If you need to create OR logic then you
need to do this by creating multiple business rules acting on the same field.
Conditions can compare fields (they must be of the same data type), compare to a value or use basic
mathematical operators to compare with a formula working with numeric values.
Business Rules can: 1)
2)
3)
4)
5)
Set a field value
Set a field read-only (locked/unlocked)
Set a field visible/invisible (business rules cannot show/hide whole sections or tabs)
Set business required or not (you can’t set business recommended with rules)
Display an error message
Note that if you set a field value using a business rule, the onChange handlers for that field DO NOT fire.
CHAPTER 8: VIEWS
CRM has three types of views; public, private and system.
Public – Globally available views for an entity.
Private – Views created by a user for their own personal use. These need to be shared to expose them
to other users. You cannot convert private views to public or vice versa.
System – special views used in specific parts of the application such as Advanced Find, Associated,
Lookup, Quick Find. These can be customized but you can’t add new ones or delete them. They also
cannot be used in sub-grids or lists on a dashboard.
When you create a new custom entity, CRM creates a set of standard public views depending on
whether the entity is an activity entity, has follows, uses connections and whether it is owned by a user
or a team.
The public views created automatically by CRM cannot be deleted, only deactivated. System
Administrators and Customisers can add extra, new custom views however and these can be deleted.
Security roles do not affect what views are available to a user but they do affect what records get
displayed for the selected view.
Views are stored as FetchXML. Views can use parameters which are passed to the query and return
data depending on some specific value (the current user, the current date). You set these up in
Advanced Find by selecting dynamic values like “current user” or “current date”.
Views can display data from the chosen entity and any parent entities, they cannot display data from
child entities (as there could be multiple). They also cannot display data from parents of parents.
There are no limits on the number of columns that can be displayed in a view but you should limit the
number to be sensible with the amount of data returned. You can select up to two columns for the
default sorting.
Every entity has a single advanced find view. The definition for this view is used as the basis for new
personal views that are created.
The associated view is new to CRM 2013 – it is the view used when selecting to see the data associated
with a primary entity by clicking on the down arrow next to that record’s name in the primary
navigation. So if we are on an Account form for example and will click the down arrow in the navigation
and select Contact then we get a full page list of contacts linked to that account which uses the
Associated View. Interestingly, Associated Views cannot be used for sub-grids – as we mentioned at
the start of this chapter, the system views can’t be used in sub-grids. Sub-grids must use a public view
for that entity.
Some entities have more than one associated view, such as Activities which could be shown in the list of
Activity and Notes and in the full-page “associated” data as described in the previous paragraph.
Contacts have two associated views, the normal one for showing contacts linked to something and an
extra one for showing contacts in a marketing list.
Quick Find views have view and find columns, the system will match the search terms using “begins
with” with all of the find columns – this makes use of indexes in SQL Server. Find columns can only
come from the entity being searched, not from other linked entities. The user can add a “*” wildcard
but this may give bad performance as indexes will not be used. Searching is not case-sensitive.
Each time you add a Find column, CRM adds a non-clustered index to the underlying database table the
next time the index maintenance job is run. If you add more than 20 fields or a field longer than 900
characters then CRM no longer creates indexes and MSFT suggest that you add them directly yourself in
the database if you really need them! Removing a find column also removes its index.
Look Up Views are used by look up lists to display a list of possible parent records for a lookup field. The
primary field and two other fields are shown. The primary field must always be shown and you can’t
remove it when customizing this view.
Note that the “+ New” button in these look up fields will open the Quick Create form if it is enabled for
the entity and if not, the main data form.
Note that the look up view is used by default for look up fields but you can use the Form Editor to
change this and actually use a different view for a Look Up field. Look ups use the fields defined for the
Quick Find view to perform their searching when you type in to the look up box.
You can modify the out of the box Look Up view but not delete them or create new ones.
A new feature is that for tablets, a global search can be launched which works across up to TEN entities.
Type in “Redmond” and it will return ten separate lists showing he contacts, accounts, opportunities etc.
in which the fields as defined in the Quick Find view for each entity, match on that term.
The entities that are involved in the tablet search can be configured via the Settings > Administration >
System Settings – see the next screenshot.
The customization of views is as it was in CRM 2011, the course notes cover the View Editor, building the
filter criteria and setting up the display columns. There is no limit to the number of columns you can
display and remember that the Display Name is always used for the column title and cannot be changed
in the View. You have to modify this in the entity definition if you wish to change it – and then it is
changed globally. For this reason MSFT suggests that you should chose Display Names mindful of VIEWS
and not FORMS (where you can override it).
By default Views are sorted by the Primary Field. The Primary Field is the only field shown by default in
a new view. You can sort on up to two columns but you can’t sort on columns from the entity’s parent.
You can specify one View as the DEFAULT View for that entity type. Out of the box this will be the “My
Active X” View. Users can also override this and chose their own personal default view.
System Views cannot be deactivated or deleted.
Public Views can be either deactivated or deleted apart from some special Public Views created for
system and custom entities which cannot be deleted. Remember though that you can’t delete via a
Solution Package, you’d have to visit the system and manually delete the view.
Note also that if we create a chart that is based on a view which we then deactivate, this can lead to
unexpected behavior. You should therefore consider everywhere that a view is used before deactivating
it.
CHAPTER 9: CHARTS & DASHBOARDS
Charts
Charts can be embedded in single record forms, shown alongside lists of data or put on dashboards. You
can create system charts available globally or users can create their own personal charts. Personal
charts can be shared. Charts include data from one entity type only.
System charts can be deleted and modified. Elsewhere “System” means fundamental for CRM to
operate. In the context of charts, System just means globally available.
You can display up to FIVE series grouped by one CATEGORY, or one series grouped by up to two
categories.


SERIES – the collection of data to plot.
CATEGORY – splits a series in to data points to compare to one another
Using the Report Designer UI you can’t design the View underlying the chart, the filter of records or the
colours of the chart.
Personal Charts can’t be included in solutions but they can be exported as XML and reimported to
another CRM instance – this will change a personal chart in to a system chart! Manually changing the
XML is the best way to achieve complete control over a chart. The exported XML contains no
information about the underlying view that the chart uses or the CRM version so that you can exchange
reports from CRM 2011 to CRM 2013.
At import a new GUID is assigned for personal charts so MSFT recommend immediately exporting a
chart after import to have a version of the XML file with the right GUID in it! For system charts MSFT
will check to see if the GUID exists and if it does will prompt you to overwrite and replace or create a
new chart with a new GUID.
CRM 2013 can display many different report types since it is based on SSRS but using the visual designer
only a limited number of chart types are available. The chart designer must choose between multiple
(up to five) series and one category or one series and up to two categories. Depending on the
combination certain chart types will be available. A stacked column or 100% stacked column chart
subtype is only possible for example if you have multiple categories.
You can choose the chart subtype to stack multiple series but results may be unpredictable, it sounds
like the designer is not stable enough for this. MSFT recommend that you export the report XML
definition and edit this to be sure you get what you want.
When displaying multiple series you can provide a different chart type for each but there are some
restrictions on what you can mix. Pie and Funnel charts can only use a single series for example.
When creating a system view you select a Public view to use when previewing the chart during design.
This view is not saved with the chart definition but it only used when designing the chart to provide
some data. Private charts are built using the View that is open next to the chart pane when you begin
designing.
The sort order and display columns of the underlying view have no effect on the chart – charts can
display any columns, and are not limited to those in the view, for example. For convenience however,
the columns displayed in the View are shown at the top of the Series selector when building your chart
with all other fields below. Charts are sorted based on the categories chosen for them, not the sorting
of the underlying view.
Because views can use columns from parent records of the entity being viewed, these are available in
the Chart designer to build charts that incorporate data from the entity and its parent.
Aggregations are used in charts – any numeric types can have mathematical operators applied (sum,
count, average) and non-numeric types can only have count applied.
If performing a count use the GUID – entityid field as this can be relied upon to always contain a value.
If you use a date time as a category field then the Chart Designer will provide an additional option to
allow you to group by day, week, month, quarter etc. CRM 2013 uses the US date format approach in
which Sunday is the first day of the week. This differs from the European standard so be careful!
Be careful when grouping by dates because if no data exists for one day, week, month then that does
not appear on the axes and so the INTERVAL between axes points will not necessarily be proportional to
time e.g. March might be followed June if April and May contain no data. MSFT recommends against
using line charts for this type of visualization as they give the impression of showing continuous data.
You can select date and time for both the primary and secondary category but only if the secondary
category is at a smaller date resolution than the primary.
You can use Top X and Bottom X to filter down to the biggest, smallest set of values in your underlying
record set. X can be up to 100. These rules also sort the data for extra clarity.
Be careful when adding GUID lookup fields from a parent entity as the chart will sort on the numeric
GUID value! Better to add a meaningful field like the account name and ensure that the category works
on that.
A trick to sort by a series value is to provide a Top or Bottom rule whose number is greater than the
number of categories you are plotting – a bit like SELECT TOP 100% in SQL perhaps (Course Notes 9 Page
17)? The notes state that this will force a sort on the series without limiting the data.
Dashboards
As with charts, dashboards can be system or personal. System dashboards can only use elements that
are globally available in CRM and they can be included in solutions (be careful to also include the
elements that the dashboard contains in the same solution) and specific security roles assigned to them
to control which users have them available.
Personal dashboards are user-defined and owned and cannot be placed in solutions. You can’t change
dashboard types to upgrade a Personal to a System but you can share a dashboard.
You can provide a description for a dashboard, but this can only be done when you first create it and
you won’t be able to easily change it afterwards. MSFT recommend that you use Save As to create your
dashboards rather than starting from scratch.
Above is the screen for selecting the security roles that can access a dashboard, accessed from within a
Solution file. MSFT recommends creating a Security Role for dashboard that is assigned to a team (or to
the default team for a business unit) to easily allow you to open up access by placing users in that
team/business unit. If you take this approach, make sure that the security roles are in the same solution
as the dashboard if you export the solution.
Available dashboards are shown to the user in alphabetical order and there is no preferred ordering as
there is with forms.
Each area of CRM (Sales, Marketing etc.) has its default dashboard and if the user cannot access this
then they get to see the System default dashboard. You can’t use tools in the UI to change the area
default dashboard so MSFT recommends saving a copy of the current default dashboard and then
changing that.
Dashboards, like forms, are laid out with tabs and sections within tabs. The UI proposes default layouts
when creating a dashboard from scratch. Items in a dashboard can span multiple sections for a more
flexible layout. Tabs are fixed and cannot be added or deleted but they can be renamed. Dashboard
display will adapt to the device being used to view the dashboard – elements will be placed vertically for
viewing on small devices like smartphones.
You can’t have more than four columns in a tab via the dashboard UI designer. If you need more
flexibility then, like charts, you must work with the exported XML.
CRM 2013 has a dashboard named Sales Dashboard. This is the ONLY dashboard that is delivered to the
tablet application. There is no functionality to choose a different dashboard on a tablet. Only charts
and lists can be displayed on the tablet – not IFRAMEs or Web Resources. If you need to, you must
customize this dashboard to provide a different tablet experience.
When placing a chart on a dashboard you choose the view that the chart will be based upon from the
list of available views. The view can be built with a filter that uses relative dates – show data for the
next 3 months for example. Be careful that next 3 months does NOT mean next 3 whole months – it
means 3 months from today so would only include SOME of the records from the last month. If you
need the next 3 WHOLE months, then a filter based on fiscal periods is MSFT’s recommendation – be
careful as the filter based on the fiscal period will not include the CURRENT month and so you’d need to
build a View filter with an OR condition that brings in the current month.
You cannot put more than SIX items on a dashboard. You can change this limit for CRM on-premises
using a PowerShell command. You can place more than six items on a dashboard in edit mode but you
will be blocked from saving it.
You can use the arrow keys or the mouse to move items on a dashboard and the SHIFT+arrow to make
items larger or smaller. Vertical height always increases/decreases in multiples of three. For finer
control you must work with the XML directly.
You can edit the properties of components on a dashboard. Labels are only shown for lists if you specify
that the Label is to be Shown AND turn on View Selector. Charts display the label as their title and this
can’t be changed.
You cannot show a list of DATA and its associated CHART(s) in a dashboard. Better to show the chart
and have the user open the raw data view with the menu icon.
CHAPTER 10: ADDITIONAL SECURITY OPTIONS
In addition to the Business Unit and Security Role model there are two other options for security and
data access: 1) Field Level Security
2) Access Team Templates
Field Security
Field Security is enabled by turning it on for the field in question, creating a field security profile that this
field uses and assigning the profile to a team that the users you want to be able to access the field
belong to. The screenshot for doing this within a solution is below. The profile lists all custom fields
that have had field level security turned on but you don’t have to set permissions for all of them – you
might choose to create multiple profiles, each of which works on one field only.
If a user is assigned to multiple security field profiles then the least restrictive combination applies.
Field security can ONLY be applied to custom fields in system and custom entities.
Field security controls all channels of access to that data – reports, tables, views and even imports and
SDK access.
Fields display a list of asterisk to mask the data to those who do not have access, even if the field is
empty. A padlock icon is used to indicate that the field is a read-only one. A key symbol indicates that
the field is protected by field security.
The permissions for access are READ, UPDATE and CREATE.
Permissions work independently, I could be granted permission to update a credit card number but then
not view it after it has been saved!
If a user only has CREATE permissions on a field then it should be Business Required to ensure that they
do not miss their one and only chance of setting it!
A special Administrator Field Security Profile exists within CRM which cannot be added to a solution and
which automatically gets rights to field level security-protected fields so that the Administrator can work
with them.
The other security mechanisms in CRM like sharing do not affect the field level security, it is the lowest
level of security and will take precedence.
Access Team Templates
New to CRM 2013, Access Team Templates provide a way of providing access to data for a group of
other users in a way that is much more visible than the usual “Sharing” functionality and can be queried
through Advanced Find as it is based on CRM’s native team and user security model. The other
advantage is that when using an access team, the person granting permission does not have to decide
what access level the person has, this is already set as part of the access team definition.
The classic example is setting up a list of stakeholders that need access to a Project entity.
To enable Access Teams you must: 1) Turn on Access Teams for that entity.
2) Create an Access Team Template that specifies the permissions for accessing the record.
3) Add a sub-grid to the entity form in question that users can use to add/maintain the access
team members (the users). The sub-grid relates to the specific Access Team Template.
At most you can use TWO Access Team Templates per entity and you can enabled access teams for FIVE
entities. For on-premises deployments you can change these limits with a PowerShell command.
After setting up an Access Team Template, a CRM team is auto-created when the first user is added to
the subgrid. The name of the team will be the GUID of the record a + and the GUID of the access team
template. These teams do not show up in the usual CRM team views as they are system managed but
you can still query them through Advanced Find.
The preceding diagram shows the rights you can configure for an access team. Users get these rights
through their team membership – CRM does not create individual “shares”.
Some rules are applied: 1) The user granting access to someone else must have SHARE privilege on the record.
2) The user granting access to someone else must have all the permissions he wants to grant – I
can’t give someone else Delete permission to the record if I do not have this myself.
3) The user being granted access must have the appropriate level of security access from their
security role. I can’t give a user Delete access to my record if that person does not already have
delete permissions for the entity.
If you grant SHARE permissions to someone you add then that person can add more people to the team.
Access Teams fundamentally use sharing to achieve their aim so you can’t turn sharing off for that
entity for the users that you want to put in the team. This means that these users could still share the
record in the normal way without using the access team and your only choice is to hide the Share button
if you want to try to restrict to doing everything with the team.
A lab in the training notes walks through the creation of an access team, I proceeded as follows: -
1)
Enabled Access Teams for Contacts using the
default base solution directly.
2)
In the Administration area of Settings, created a
new Access Team Template relating to Contact. I was
pretending that this was the HR team working with this
individual.
3)
In the Main Information form for Contact you
need to ADD a sub-grid.
4)
You need to specify the Data Source as ALL
RECORDS since users do not have a direct relationship
to the Contact but an indirect one through their team
therefore the “Only Related Records” option will not
work.
5)
The Entity is USER.
6)
You must select the default view as “Associated
Record Team Members”.
7)
A “Team Template” option will then appear in
which the Access Team Templates for the current
entity are shown.
8)
Publish these customisations of course!
9)
The grid now appears on the Contact form and
is available for use.
Very good blog on Access Teams here: http://blog.customereffective.com/blog/2014/01/adventures-in-microsoft-dynamics-crm-accessteams.html
The blog points out the important facts that: 1) The SHARE permission for the entity using the Access Team controls who can add new members
to the Access Team.
2) Access Teams work via sharing and so any cascade rules set up for relationships that cascade on
SHARING will apply. This is a good feature, if we add a user to our Contact form to be able to
work on that contact then the cascade rule (if configured) would give that user rights to the
Opportunities, Activities etc. belonging to that contact.
3) The Access Team is created when the first member is added and programmatically you can’t just
create a team and put a member in it yourself, there is a special SDK method for doing this
correctly. KingswaySoft connector also handles this correctly.
4) You can manually create Access Teams (see the screenshot below) but you can’t them link them
to Access Team Templates and use them in the way that was intended (and practiced in the
preceding lab). The reason you might want to manually create them is that they are effectively
a light-weight team without a queue and without the possibility of owning records and so might
suit some specific scenarios.
5) Maximum of two access team templates per entity – so you could have a read team and a write
team and two grids on the entity form.
6) Access Teams can’t be moved as part of a solution and because the grid you have placed on a
form will be linked to the specific GUID of your access team, you can’t even recreate the team
and expect it to work. The only solution is to move the access team with an ETL tool that
preserves the GUID as there is no EXPORT/IMPORT option for Access Teams.
7) You can’t manually share records with an Access Team – it has been designed to provide quick
lightweight sharing for one entity only so you can’t go adding additional records.
Auditing
Auditing in CRM can be enabled at: 1) The organisation level.
2) The entity level.
3) The individual field level,
And…


Entity-level auditing will only occur if organization level auditing is turned on.
Field-level auditing will only occur if entity and organization level auditing is turned on. When
you enable entity auditing, all fields are turned on for auditing by default.
This hierarchy means that we can set up the auditing configuration in a development system but leave
organization-level auditing off to ensure that no actual work occurs and incurs an overhead.



Organisation-level auditing tracks system-level changes such as a security role being assigned to
a user or auditing being turned off. You can optionally audit user access to CRM.
Entity-level auditing tracks when a field is added to an entity.
Field-level auditing is the changes to actual CRM data within entities.
Note that since 1:N relationships are modelled by a lookup field on the CHILD, when a record is reparented then auditing captures this at the child, and not audit record on the PARENT is generated.
You can view the Audit History either directly on a record via the “Audit History” link in the associated
data of the current record (this shows the field-level audit records): -
Note that this is not of course available for a deleted record.
You can show an Audit Summary via Settings > Auditing. This shows the Organisation and Entity level
changes and a summary of the Field-Level changes.
The way auditing works, technically is to store the old value with the user and date and time in a
dedicated SQL Server table. For the new value the query either looks at the next newest audit record or
at the current record if no newer audit record exists.
This means that if you disable auditing you get a potentially partial view of data changes as logs are not
written and the newer audit record will not be present.
Permissions to View Audit History and View Audit Summary can be set as part of a security role. Field
security will apply so that sensitive fields in the audit log will be masked for users that can’t access them.
You can’t control access to the audit log on an entity-by-entity basis because the security looks at the
overall READ permission for that entity – if a user can read any given entity, they can also read the audit
logs.
Audit logs are stored per quarter, and a user with appropriate permissions can delete these logs. Only
the EARLIEST log can be deleted to ensure logs are removed in the correct order and the most recent
audit log can never be deleted. The removal of logs is itself an event written in to the audit log and so
the most recent quarter will record this.
A SQL Server Enterprise back end actually splits the quarters in to different partitions.
CHAPTER 11: BUSINESS PROCESS FLOW
Business process flow provides step by step guidance to ensure that operations are carried out in a
consistent manner. First introduced as an update in CRM 2011 it is now much more extensive in CRM
2013. They live within the whole landscape of “processes” within CRM: 


Workflows – implements some automated logic and triggered by a data change or other record
event, can run synchronously or asynchronously and loop, brand, add/change data etc.
Dialogs – a guided set of screens to allow the user to interact and enter data. Cannot be saved
halfway through.
Business Process Flows – started when a record is created, no branching logic – a set of linear
steps. A user can change business process flows but only ONE is associated with the record at
any one time. They do not enforce business logic, merely guide the user but can be combined
with business rules or workflows.
25 system entities can be enabled for business process flows (and no more system entities) and any
custom entity can have business process flows enabled.
Processes are configured in Setting > Processes for the default solution or within your own solution.
You design a business process flow by choosing the entity that is FIRST used by the flow. This can’t be
changed after it is initially selected. The designer includes a Stage Category which is not shown to the
user but is useful for reporting.
You specify the fields of data collected at each step and if one of these is required then it must be
completed before the user can move to the next stage.
You can only design processes when they are inactive, as soon as you activate them they become readonly. You can do “Save As” to work with a copy of the process but this will create the copied process in
the default solution. To work in a proper solution file you need to use “Add Existing”.
You can have up to TEN active business processes per entity.
New business process flows imported from a solution file will have the activation state of when the
solution was created. (P270 of Customization document in Implementation Guide).
Processes contains STAGES and STEPS. A process can have up to 30 stages in total spanning, at most,
five entities.
Stages define the arrow sections in the graphical representation of the flow. Each stage relates to an
entity. You can pass to any entity in an N:1 relationship with the entity in the previous stage e.g. go
from a contact to an opportunity. The user can search for opportunities or choose to add a new one. If
adding a new one then the data MAPPINGS for creating that record apply just as if the user had opted to
create a new opportunity from the contact form sub-grid or associated view.
In the process editor there is an option to “Close Process Cycle” which means use the same entity that
was already created/used earlier in the process rather than create a new one. The user is not given the
option to create a new entity of that type.
Any field can be used within a stage, even one that does not appear on the main form. If it is on the
main form then as soon as the user enters data in either place, it is synchronised to the other instance of
the field on field lost focus. Any business rules or form script related to a field will be run, even if
triggered from the business process flow control – hiding a field will hide it in the form and the process
bar for example.
Read only fields on the main form will be available in the process control. Field level security is applied
to fields in the process bar correctly.
You can make a field in a process flow REQUIRED even if the field on the form is not. The user will not
be able to continue to the next stage until data is provided for this field.
Users can click forward and backward in the process arrow to see the fields associated with those stages
without actually advancing the CURRENT step they are on. If a step involves the creation of a related
entity then that step is shown with a padlock to indicate that the entity does not yet exist.
Security
Access to business process flows is controlled through security roles just like forms and dashboards.
Upon creation only the System Administrator and Customizer have access to the process flow so that it
can be tested. MSFT recommend setting up security roles that ONLY give process access to keep things
nice and clear.
When multiple processes are available to the same user you can specify the process order. When the
user switches processes they begin at the first stage of the selected process. They can only switch to a
process whose primary entity (starting entity) is the same as the current entity… for example if I start in
a Contact and then create a new Opportunity and then opt to switch processes, I must swap to an
Opportunity process.
Only one process is associated with a record globally at one time. So if I swap from process 1 to process
2 for a contact then the next user to view that contact will see Process 2 as active. If their security does
not give them rights to this process then it will be disabled.
MSFT suggests using a combination of Field Security and Business Process flows to create an approval
step – effectively ensuring that only a certain user(s) can entered a value that is required to move to the
next stage in the process. Be careful however as all users that use the process will need READ
permission on this field, if one of them does not have it then CRM, accessing the page in their context,
will also not be able to read the field and will just assume that it DOES contain a value.