2. Customization
The customization file contains all the
customizations for a specified set of entities and
configuration elements.
(OR)
Modification of Entities
3.
4.
5.
6.
7.
8.
9.
10.
11. Solutions
Solutions are how customizers and
developers author, package, and maintain
units of software that extend Microsoft
Dynamics CRM 2011. Customizers and
developers distribute solutions so that
organizations can use Microsoft
Dynamics CRM to install and uninstall the
business functionality defined by the
solution.
12. Entity Definition
The entity definition area includes a
number of different important settings as
follows:
Display Name / Plural
Name: These two fields represent the
name of the entity as it will appear in
Dynamics CRM. In some contexts the
plural name will be used, and in
others the display name will be used.
These values can be changed later if
desired.
13. Name: This field is the name that
the entity will be referred to if it is
referenced within custom code
including custom reports, JScript,
or other programming code. This
field cannot be changed after the
entity has been saved for the first
time.
14. Description: This field is an optional
field with more information on how the
entity will be used within Dynamics
CRM. It is a best practice to enter text
into description fields that documents
how the entity will be used. By entering
this documentation, you will make it
easier to support your instance of
Dynamics CRM in the future.
15. Ownership
This field determines who will own each
record in the entity. Another way to think
about ownership is to ask, “Who will be
responsible for maintaining this record in
Dynamics CRM?” This field plays an
important part in defining security roles
and in establishing views and charts of
data. After you select a value for this
setting and save the entity, you cannot
change it. Options for this field are as
follows:
16. User or Team: Select this option if
every record in this entity will be
“owned” by a user or by a team of
users. For example, if you create an
entity to track projects, then you will
most likely want to use this setting
because your projects will be assigned
to an owner who is responsible for
making sure that his or her projects are
managed properly.
17. Organization: Select this option if
records won’t be owned by any particular
individual or team. For example, if you
create an entity to track customer
inventory, then you will most likely want to
use this setting because this inventory will
not be owned by a particular user (or
team) in your business.
18. Entity Relationships Behavior in CRM
2013
Before describing how to configure entity
relationship behaviors it is useful to
consider how it applies to your business.
Three key concepts are:
Preserve Data Integrity
Automate Business processes
Cascading behavior
19. Preserve Data Integrity
Each entity can have rules that define a valid
record. For example, a Microsoft Dynamics
CRM opportunity record must include a
reference to a potential customer. Users
cannot create a new opportunity record without
either adding an existing customer or creating
a new customer record.
But what should happen if the account or
contact that represents the customer is
deleted? In a case like this, possible
alternatives are to either:
20. Preserve Data Integrity
Restrict any attempt to delete a customer
record with an associated opportunity.
Cascade the delete action when a
corresponding customer record is deleted
so that any related opportunity records are
automatically deleted.
21. Example
In Microsoft Dynamics CRM for the one-to-
many relationships that relate opportunities
with customers, such as
Opportunity.opportunity_customer_accoun
ts &
Contact.opportunity_customer_contacts,
the behavior is to cascade the delete action.
When you model your data to use in Microsoft
Dynamics CRM you will have similar
decisions for how you want to preserve data
integrity.
22. Automate Business Process
Your business processes may require you
to perform actions on records that have
related records. For example, you may
need to assign an account to a new
salesperson. If that account record has
any opportunity records, some options
include:
23. Automate Business Process
Do nothing:-The opportunities should
continue to be owned by the individuals who
work on them.
Assign all the opportunities to the new
salesperson :- As the new owner of this
account record, the salesperson is now
responsible for all opportunities related to that
account.
Only assign the active opportunities to the
new salesperson:- Preserve the owner for
any inactive opportunity records for reporting
purposes.
24. Automate Business Process
Only assign the opportunities owned by the
previous account owner to the new
salesperson:- This allows the new salesperson to
replace the previous owner.
These options are common ones you can
configure using entity relationship behavior in
Microsoft Dynamics CRM. If you require different
behaviors consider purchasing a solution
containing the behavior you need or developing a
plugin to provide additional options.
25. Cascading Behaviors
These configuration options
are called cascading behaviors
because they cascade down
the hierarchy of related entities
26. Example
if deleting an account causes related
opportunities to be deleted, what about
the activities associated with the
opportunities? In Microsoft Dynamics
CRM the behavior defined in each of the
entity relationships for activity type entities
is that they are deleted as well.
27. Example 2
However, not all entities are treated this way. For
example, orders and invoices contain important
business data that shouldn’t be inadvertently
deleted. They have entity relationship behavior
configured to restrict deleting customer or
opportunity records that they are associated with.
Before you can delete the customer or opportunity
that has a related order or invoice record, you
must delete the order or invoice first.
As you model your business data by creating
custom entities or when using existing Microsoft
Dynamics CRM system entities, consider the
behavior you require and the implications for the
entire hierarchy of related entities.
28. Parental Entity Relationships
Each pair of entities that are eligible to have a
1:N relationship can have multiple 1:N
relationships between them. Yet only one of
those relationships can be considered
a parental entity relationship.
A parental entity relationship is any 1:N entity
relationship where one of the cascading
options (defined in CascadeType) in
the Parental column of the following table is
true.
29. Action Parental Not Parental
Delete Cascade Remove Link
Restrict
Share CascadeUserOwnedActive No Cascade
Unshared CascadeUserOwnedActive No Cascade
Assign CascadeUserOwnedActive No Cascade
Reparent CascadeUserOwnedActive No Cascade
30. Each referencing entity in a 1:N entity
relationship has one referencing attribute where
the relationship can be considered parental.
For example, if you create a new custom entity
and add a 1:N entity relationship with the
account entity where your custom entity is the
referencing entity, you can configure the actions
for that entity relationship to use the options in
the Parental column. If you later add another
1:N entity relationship with your custom entity as
the referencing entity you can only configure the
actions to use the options in the Not
Parental column.
31. Usually this means that for each entity pair
there is only one parental relationship.
There are some cases where the
referencing attribute on the referencing
may include a reference to more than one
type of entity.
32. Example
For example, the Opportunity entity has a
referencing attribute called customerid where
a reference to either a contact or account
record may be stored. There are two separate
parental 1:N entity relationships in this case.
Any activity entity, for example, a task, fax,
phone call, and so on, has a similar set of
parental entity relationships for entities that
can be associated using
the regardingobjectid referencing attribute.
33. Configuring Entity Relation
Behavior
When you use
CreateOneToManyRequest or
UpdateRelationshipRequest you include an
instance of a
OneToManyRelationshipMetadata class in the
body of the request. In the CascadeConfiguration
property of that class you use
the CascadeConfiguration class.
The CascadeConfiguration class contains the
properties representing actions that may be
performed on the referenced entity in the one-to-
many entity relationship. Each property can be
assigned one of the values of
34. CreateOneToManyRequest :-Contains the
data that is needed to create a new One-to-
Many (1:N) entity relationship.
UpdateRelationshipRequest :-Contains the
data that is needed toupdate the definition of
an entity relationship.
OneToManyRelationshipMetadata:-Contains
the metadata for a one-to-many entity
relationship.
36. Value Application label Description
Active Cascade Active Perform the action on all active
referencing entity records associated with
the referenced entity record.
Cascade Cascade All Perform the action on all referencing entity
records associated with the referenced
entity record.
Non
Cascade
Cascade None Do nothing.
Remove
Link
Remove Link Remove the value of the referencing
attribute for all referencing entity records
associated with the referenced entity
record.
Restrict Restrict Prevent the Referenced entity record from
being deleted when referencing entities
exist.
User Owned Cascade User
Owned
Perform the action on all referencing entity
records owned by the same user as the
37. The CascadeConfiguration class
contains the following properties
representing actions that may be
performed on the referenced entity
in the one-to-many entity
relationship.
38. Action Description Valid Option
Assign The referenced entity record
owner is changed.
ActiveCascadeNoCascadeUs
er
Owned
Delete The referenced entity record is
deleted.
Note:-
The options for this action are
limited.
CascadeRemoveLinkRestr
ict
Merge The record is merged with another
record.
Note
For referenced entities that can be
merged, Cascade is the only valid
option. In other cases use
NoCascade.
Cascade NoCascade
Reparent See
The Reparent Action following.
Active
Cascade
NoCascade
39. Action Description Valid Option
share When the referenced entity
record is shared with another
user.
Active
Cascade
NoCascade
UserOwned
Unshare When sharing is removed for the
referenced entity record.
Active
Cascade
NoCascade
UserOwned
40. The Reparent Action
The Reparent action is very similar
to the share action except that it
deals with the inherited read
access rights instead of explicit
read access rights.
41. How Record-Based Security Can Be Used to Control
Access to Records in Microsoft Dynamics CRM
Record-based security in Microsoft Dynamics CRM
and Microsoft Dynamics CRM Online applies to
individual records. It is provided by using access
rights.
The relationship between an access right and a
privilege is that access rights apply only after
privileges have taken effect. For example, if a user
does not have the privilege to read accounts, that
user is unable to read any account, regardless of
the access rights another user might grant to a
specific account through sharing.
42. Access Rights
Access right Access Right
enumeration
value
Description
Read ReadAccess Controls whether the user can read a record.
Write WriteAccess Controls whether the user can update a
record.
Assign AssignAccess Controls whether the user can assign a
record to another user.
Append AppendAccess Controls whether the user can attach
another record to the specified record.
The Append and Append To access rights
work in combination. Every time that a user
attaches one record to another, the user
must have both rights. For example, when
you attach a note to a case, you must have
the Append access right on the note and the
An access right is granted to a user for a particular record.
The following table lists the descriptions for these access
rights.
43. Access
right
Access Right
enumeration
value
Description
Append To AppendToAcce
ss
Controls whether the user can append the
record in question to another record.
The Append and Append To access rights
work in combination. For more information,
see the description for Append.
Share ShareAccess Controls whether the user can share a
record with another user or team. Sharing
gives another user access to a record. For
more information, see Sharing Records.
Delete DeleteAccess Controls whether the user can delete a
record.
44. Create Access
The right to create a record for an entity type is
not included in the previous table because this
right does not apply to an individual record, but
instead to a class of entities. Create is handled
as a privilege instead of as an access right.
The user who creates a record has all rights
on that record, unless his or her other
privileges forbid a specific right
45. About Dependencies Between Access
Rights
Sometimes, security dependencies exist because
it is necessary to have more than one access
right to perform a given action. For example, if
you have the create access right for accounts,
you can create a record of the account entity
type. However, unless you also have read access
for accounts, you cannot create an account
record and be the owner of that new record.
The following table lists the access right
dependencies for the actions specified.
46. Action Access rights required
To Create a record and be
the record owner
CREATE , READ
To Share a record SHARE. This right is required by the person doing the
share operation.
READ. This right is required by the person doing the
share operation and also by the person with whom the
record is being shared
To Assign a record ASSIGN , WRITE ,READ
To Append To a record READ , APPENDTO
To Append a record READ , APPEND
47. Another type of dependency exists when
objects are subordinate to another object.
the opportunity object cannot exist on its own.
Each opportunity is always attached to an
account or contact. To create an opportunity,
you must have the access right appendto on
accounts and the access right append on
opportunities.
Example
48. Sharing Records
Sharing lets users give other users or teams
access to specific customer information. This
is useful for sharing information with users in
roles that have only the Basic access level.
For example, in an organization that gives
salespeople Basic read and write access to
accounts, a salesperson can share an
opportunity with another salesperson so that
they can both track the progress of an
important sale.
49. For security reasons, develop the practice of
sharing only the necessary records with the
smallest set of users possible. Only grant the
minimum access required for users to do their
jobs.
Microsoft Dynamics CRM provides the
following sharing capabilities:
Share
ModifyShare
Removeshare
50. Share
Any user who has share privileges on
a given entity type can share records of
that type with any other user or team in
Microsoft Dynamics CRM. To share a
record, use GrantAccessRequest.
51. When you share a record with another user, indicate what
access rights (Read, Write, Delete, Append, Assign, and
Share) you want to grant to the other user.
Access rights on a shared record can be different for each
user with whom the record is shared.
However, you cannot give a user any rights that he or she
would not have for that type of entity, based on the role
assigned to that user.
if a user does not have Read privileges on
accounts and you share an account with
that user, the user will be unable to see that
Example,
52. ModifyShare
You can modify the rights granted to a
shared record after it has been shared. To
modify sharing for a record, use
the ModifyAccessRequest.
53. Remove Share
If you share a record with another user or
team, you can stop sharing the record.
After you remove sharing for a record, the
other user or team loses access rights to
the record. To remove sharing for a
record, use the RevokeAccessRequest.
54. Assigning Record
Anyone with Assign privileges on a record can
assign that record to another user. When a
record is assigned, the new user or team
becomes the owner of the record and its
related records. The original user or team
loses ownership of the record, but
automatically shares it with the new owner.
55. Retrieving the Access Rights for
Record
Use
the RetrievePrincipalAccessRequest message
to retrieve the access rights the specified
security principal (user or team) has to a
record.
Use
the RetrieveSharedPrincipalsAndAccessRequ
est message to retrieves all the security
principals (users or teams) that have access to
a record, together with their access rights to
that record.
56. RetrievePrincipalAccessRequest :- Contains
the data that is needed to retrieve the access
rights of the specified security principal (team
or user) to the specified record.
RetrieveSharedPrincipalsAndAccessRequest :
-
Contains the data that is needed to retrieve
all security principals (users or teams) that
have access to, and access rights for, the
specified record.
70. Global Option Set
Typically, you use global option sets to set
fields so that different fields can share the
same set of options, which are maintained in
one location. You can reuse global option sets.
You will also see them used in request
parameters in a manner similar to an
enumeration.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83. Business Rules is new functionality in Microsoft
Dynamics CRM 2013, with Business Rules you
can apply form logic without writing JavaScript
code. Business rules provide a simple
declarative interface to implement and maintain
fast changing, commonly used business rules
that will be applied to Main and Quick Create
forms for both the web application and
Microsoft Dynamics CRM for tablets.
Business Rules in Dynamics
CRM 2013
84. Business rules can be set to apply to all Main or Quick Create
entity forms or specific Main forms that you choose. You can
transport business rules from one organization to another by
including them in a solution and you can install solutions that
contain business rules.
Business rules allow for a subset of the capabilities provided by form
scripts. With Microsoft Dynamics CRM 2013 and Microsoft Dynamics
CRM Online, you can define conditions and apply the following actions:
What can Business Rules do?:
1. Set field values
2. Set field requirement levels
3. Show or hide fields
4. Enable or disable fields
5. Validate data and show error messages
85. Configure Business Rules: First, you need to have the
privileges necessary to navigate to Settings > Customization.
This typically requires the System Administrator or System
Customizer security role. To activate a business rule, you
must have the Activate Business Rules privilege.
There are four ways you can view, create, or edit business rules:
1. Solution -> Entity From a solution, such as the default
solution, you will find a Business Rules node for all entities
86.
87. 2. Solution -> Entity -> Field When you view an entity field, you will find
a Business Rules node that will show you only the business rules that include
this attribute.
88. 3. Form Editor From the form editor, you can use the Business Rules button in
the ribbon to show the Business Rules Explorer on the right side. This will show
you all business rules that will be applied just for this form. If you create a rule from
the form editor, the default scope is for that form.
89. 4. Form Editor -> Field When you view the properties for a field that is used in a
form, you will see a Business Rules tab that shows you the business rules that
include this attribute. If an existing rule is similar to a rule you want to make, you can
open that rule and use the Save As button to copy an existing rule as a starting point
for a new rule.
90. Set the scope: In the top right of the form, use
the Scope field to set the scope for the rule to
All Forms or choose any one of the Main
forms. You cannot select multiple specific
forms. If you choose All Forms, the rule will be
applied to all the Main forms and the Quick
Create form, as long as the form includes all
the fields referenced by the rule. If you create
a new business rule by using the form editor,
the default scope is just that form.
91.
92. Configure Conditions: If you want to change an activated
business rule, you must deactivate it before you can edit it.
To add a condition, click the + icon and a new condition row will
appear with default values set. Enter the field name to set the
Field, and then choose the appropriate Operator. Operator
options will change depending on the data type of the field.
Conditions are checked whenever any field referenced within
the condition changes.
You can chose three different types of conditions:
Field: Use this type to compare the value of one form field with
another.
Value: Use this type to compare the value of one form field with
a value you enter.
Formula: This option appears only for numerical or date data
types. It does not appear for fields that contain text. Use this
type to compare the result of a simple calculation that may use
either a value in another form field or a value you enter.
93. When you are finished entering or editing the rule, click or tap the check mark icon to
save it or the (X) icon to discard changes. To remove a previously saved condition,
place your cursor over the condition and click the pauseǁicon.
94. Configure Actions:
To add an action, click the + icon and you will
have the following options:
1. Show error message: Use this action to set an
error message on a field if the data within it is not
valid. The text you specify for the message will be
displayed with an error icon near the field.
The record cannot be saved as long as this
message is displayed. After the data in the field
has been corrected according to the conditions
set in your rule, the message will disappear and
the record can be saved.
95. 2. Set field value: Choose the Field and Type.
There are three types:
Field: Use this type to set the value of one form
field with the value of another field.
Value: Use this type to set the value of a form field
with a value you enter.
Formula: This option appears only for numerical or
date data types. It does not appear for fields that
contain text. Use this type to set the value to the
result of a simple calculation that may use either a
value in another form field or a value you enter.
96. 3. Set business required: Use this type to
change the requirement level for the field.
The options are Not Business
Required and Business Required. There is
no option to set this to business
recommended.
4. Set Visibility: Use this type to change
whether the field is displayed in the form.
The options are Show Field and Hide Field.
97. 5. Lock and unlock field: Use this type to
change whether the field is enabled in the
form. The options are Lock and Unlock. When
the field is locked, people will not be able to
edit the value in the field.
After you have defined an action, you can
change the order or delete it by using the
options available when you place your cursor
over the action.
98.
99. Set the description: Setting a description is
optional. It isn’t displayed anywhere else
except in the business rule editor. But it is a
good idea to include a description of what the
rule is supposed to do and why it has been
added.
Test and activate business rules: Before
anyone can use the business rules you have
created, you must activate them. Before you
activate them, you should test them. You can
test business rules by using
the Preview button in the form editor.
100. Limitations for business rules: Business rules in
this release are intended to address common actions.
Compared to what a developer can do by using form
scripts, business rules have limitations. However,
business rules are not intended to replace form
scripts.
The primary limitation you may find compared to form
scripts is that all conditions in the business rules are
evaluated using AND. All the conditions must be true
before the actions will be applied. There is no support
for OR or Else operators to provide for more complex
logic. To apply OR in your conditions, you need to
create separate rules for each condition you want to
test. This can be done efficiently by using the Save
As option and creating separate rules for each
condition you want to test.
101. Business rules run only when the form loads
and when field values change. They do not run
when a record is saved.
Business rules work only with fields. Form
scripts can interact with other visible elements,
such as tabs and sections, within the form.
When you set a field value by using a
business rule, any OnChange event handlers
for that field will not run. This is to reduce the
potential for a circular reference, which could
lead to an infinite loop.
102. If a business rule references a field that is not
present on a form, the rule will simply not run.
There will be no error message.
Whole Number fields that use the formats for
Time Zone, Duration, or Language will not
appear in the rule editor for conditions or
actions, so they cannot be used with business
rules.
104. One of the simplest and most exciting
features of CRM 2013 is the ability to
embed and display fields from the parent
entity in the form a given record. This
feature is not nearly as promoted as other
features but I like it so much I will write
about it.
Quick Views In CRM 2013
105. Many times in the past I have struggled with the need
to include fields from a related entity in the form of a
given record. Typical scenario is that you would want
to include the account number and the primary contact
of the account in the form of a given case for which the
customer is an account. Additionally, if the customer of
the case is a contact, then I’d like to display in the
case form the contact name, contact phone number
and list of activities associated with the contact in the
case form. While this was a nightmare to implement in
previous version of CRM (require custom web
resources that query and display data from related
entities), all this is possible very easily out-of-the-box
with MS CRM 2013 without having to write a line of
code.
106.
107.
108.
109. Now that I have defined the quick view forms for both the accounts and
contact, I can modify my contact form to include the related information
form the account/contact. I have created a “Customer Details” section
in the case form and will now insert the quick view forms I defined
earlier:
110. Then I need to specify the quick view forms that I will use and for which lookup
field it applies:
111. After I publish my case form, this is what it looks like if the contact of the case
is an account:
112. If I change the customer field on the case, the form is updated dynamically and the
“customer details” section is updated to display the contact quick view form I
defined:
113. You can see that I can even insert sub-grids for records related directly to my
lookup field (in this case activities related only to my customer contact). It is
also worth noting that fields from the quick view form are always read-only (e.g.
From a case form, I cannot see the phone number of the contact associated, but I
cannot edit it). If I need to edit fields from the related record I have to open the
record and edit them in the regular form.
