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 activity-type 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 Range PrecisionWhole Number + / - 2,147,483,648 0Floating Point Number + / - 100,000 million 5Decimal Number + / - 100,000 million 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 Entities Comment1:N System Primary to Custom Child Referential or Parental1:N System Primary to System Child 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.

1:N Custom Primary to System Child Referential ONLY1:N Custom Primary to Custom Child Referential or Parental but as ever only one

relationship can be parental.1:N Custom Primary to Activity/Note

ChildIf 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 new-style 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 sub-grids 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) Set a field value2) Set a field read-only (locked/unlocked)3) Set a field visible/invisible (business rules cannot show/hide whole sections or tabs)4) Set business required or not (you can’t set business recommended with rules)5) 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-access-teams.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 re-parented 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 read-only. 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.