What is an entity in MS CRM

Entity in MS CRM used to manage business data. In simple terms we can refer entity as Table in database, and, each record in an entity can refer as a row in a table. And, each field in an entity can refer as a column in table.

There are three types of entities in MS CRM.

1. System
2. Business
3. Custom

As a developer, you will be dealing with Business and custom entities. System entites are purely internal usage of CRM. We cannot customize or delete system entites. Examples for system entities are workflows and asynchronous jobs etc.

Business entities are default entities CRM provide while installing. Examples for business entities are Contact, Account, Case etc.

Custom entities are entities which we will be create as per business requirement.. 

Teams in MS CRM

            Below are the some of the interesting points about Teams

1. While a team belongs to one business unit, it can include users from other business units.
2. You can use two types of teams:
• An owner team owns records and has security roles assigned to the team. The team’s privileges are defined by these security roles. In addition to privileges provided by the team, team members have the privileges defined by their individual security roles and by the roles from other teams in which they are members. A team has full access rights on the records that the team owns.
• An access team doesn’t own records and doesn’t have security roles assigned to the team. The team members have privileges defined by their individual security roles and by roles from the teams in which they are members. The records are shared with an access team and the team is granted access rights on the records, such as Read, Write, or Append.
3. If an owner team doesn’t own records and doesn’t have security roles assigned to the team, it can be converted to an access team. It is a one-way conversion. You can’t convert the access team back to the owner team. During conversion, all queues and mailboxes associated with the team are deleted. When you create a team in the Web application, you have to choose the team type Owner.
4. A system-managed access team is created for a specific record, other records can’t be shared with this team. You have to provide a team template that the system uses to create a team. In this template, you define the entity type and the access rights on the record that are granted to the team members when the team is created.
5. A team template is displayed on all record forms for the specified entity as a list. When you add the first user to the list, the actual access team for this record is created. You can add and remove members in the team by using this list. The team template applies to the records of the specified entity type and the related entities, according to the cascading rules. To give team members different access on the record, you can provide several team templates, each template specifying different access rights. For example, you can create a team template for the Account entity with the Read access right, which allows the team members to view the specified account. For another team that requires more access to the same account, you can create a team template with Read, Write, Share and other access rights. To be added to the team, a minimum access level a user must have on the entity specified in the template is Basic (User) Read.
6. Because of the parental relationship between the team template and system-managed access teams, when you delete a template, all teams associated with the template are deleted according to the cascading rules. If you change access rights for the team template, the changes are applied only to the new auto-created (system-managed) access teams. The existing teams are not affected.

7. The maximum number of team templates that you can create for an entity is specified in the MaxAutoCreatedAccessTeamsPerEntity deployment setting. The default value is 2. The maximum number of entities that you can enable for auto-created access teams is specified in the MaxEntitiesEnabledForAutoCreatedAccessTeams deployment setting. The default value is 5.. 

Business Unit in MS CRM

                 Below are the some of the points about Business unit

1. The organization (also known as the root business unit) is the top level of a Microsoft Dynamics 365 business unit hierarchy. Dynamics 365 automatically creates the organization when you install or provision Dynamics 365. You can’t change or delete the organization name.
2. You can’t change the name of a business unit or delete a business unit after it has been created. You can disable a business unit or change the parent, however. When you disable a business unit, all users and teams associated with the business unit are also disabled.
3. Changing the parent business removes security roles for users and teams associated with the business unit. You must reassign them.
4. You can change the business unit for an individual facility, equipment, or user. By changing the business unit for a user, you remove all security role assignments for the user. At least one security role must be assigned to the user in the new business unit.
5. You can delete a business unit to completely remove it from Microsoft Dynamics 365.

                 Before deleting a business unit, be sure to consider the following:

• Deleting a business unit is irreversible.
• The records owned by the business unit are deleted at the same time you delete the business unit.
• You can’t delete a business unit until you delete any associated users, teams, and child business units.

6. You can assign a different parent business to a business unit to accommodate changes in your business requirements. When you reassign a business unit, any child business units are also reassigned with it.
7. By default, when you create a user the user has read and write access to any data for which they have permission. Also, by default, the user client access license (CAL) is set to Professional.

                 Access mode. This setting determines the level of access for each user.

• Read-Write access. By default, users have Read-Write access that allows them access to data for which they have appropriate permission set by security roles.
• Administrative access. Allows access to areas that the user has appropriate permission set by security roles but doesn’t allow the user to view or access business data typically found in the Sales, Service, and Marketing areas, such as accounts, contacts, leads, opportunities, campaigns, and cases. For example, Administrative access can be used to create Dynamics 365 administrators who can have access to perform a complete variety of administrative tasks, such as create business units, create users, set duplicate detection, but cannot view or access any business data. Notice that users who are assigned this access mode do not consume a CAL.
• Read access. Allows access to areas for which the user has appropriate access set by security role but the user with Read access can only view data and can’t create or change existing data. For example, a user with the system administrator security role who has read access can view business units, users, and teams but can’t create or modify those records.

Security roles in MS CRM

Below are the some of the points about Security roles

1. Each privilege can have up to four access levels: Basic, Local, Deep, and Global.
2. If a record is created and the parent record has certain sharing properties, the new record inherits those properties. For example, Joe and Mike are working on a high priority lead. Joe creates a new lead and two activities, shares the lead with Mike, and selects cascade sharing. Mike makes a telephone call and sends an email regarding the new lead. Joe sees that Mike has contacted the company two times, so he does not make another call. Sharing is maintained on individual records. A record inherits the sharing properties from its parent and also maintains its own sharing properties. Therefore, a record can have two sets of sharing properties—one that it has on its own and one that it inherits from its parent. Removing the share of a parent record removes the sharing properties of objects (records) that it inherited from the parent. That is, all users who previously had visibility into this record no longer have visibility. Child objects still could be shared to some of these users if they were shared individually, not from the parent record.

3. 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.
4. In Microsoft Dynamics 365, the system administrator can decide for an organization whether records should be shared with previous owners or not after the assign operation. If Share with previous owner is selected, then the previous owner shares the record with all access rights after the assign operation. Otherwise, the previous owner does not share the record and may not have access to the record, depending on his or her privileges

5. Field Level Security:

                            There are a few additional rules that apply to certain attribute data types:

• Boolean attributes can be secured for create and update operations but not for read.
• Option set attributes can be secured for create, update, and read when a default value is unspecified

6. The System Administrator field security profile gives full access to all secured fields in Microsoft Dynamics 365. By default, all users who have the System Administrator security role have this profile. This profile is system managed and can’t be updated or deleted
7. When you call the Retrieve or RetrieveMultiple methods or messages, Microsoft Dynamics 365 evaluates if the caller and the impersonated user have access to each retrieved record (this is the regular security process) and each secured field. The call does not throw an exception if the criteria contain secured fields for which the caller does not have access. Instead, null values are returned for secured fields if they are part of the output column set.
8. If the caller (or impersonated user) does not have access to the secured fields that are included in the filter criteria, the field value is substituted with null during the evaluation of the filter.
9. When aggregating on secured attributes. Secured values are substituted with a null value, so normal SQL aggregation behavior applies
10. A programmer may build a client that uses Create and Update methods that interact with secured fields. When you call the Create or Update method, passing data for secured fields and the caller does not have sufficient permissions, an exception is thrown.
11. An administrator secures a number of fields for access in the application and wants the fields not to be available in reports. This allows for maintaining the same set of reports for all users. Filtered views will not return data for the secured fields if the calling user does not have authorization for the fields. When no field security is applied for any of the view’s attributes, the filtered views return complete data.

User Management in MS CRM

Below are the some of the interesting points about user management

1. Having added the user to Office 365 and assigned a license they will exist in CRM. BUT at this stage they will not yet be able to access CRM. This is because they need to be assigned a security role in CRM. All users will be created without a CRM role in this way. With the exception of your Global Admin when the CRM instance is first created, as they will be granted the System Administrator role in CRM by default.
2. When the user was created in Office 365 we assigned a CRM license to the user, to disable the user all we do is remove the license from the user in Office 365.
3. After a short pause the user will become disabled in CRM, meaning they can no longer log into CRM. At this point it is worth considering what will happen to any records owned by the user in CRM! Well, these records will still show as being assigned to the disabled user. Meaning they will need to be reassigned to a new user. (If required.)

You can re-enable a user. When re-enabled they will have the same security role as previously assigned.

It is important to know that users are not and cannot be deleted from CRM

4. Non-Interactive Users

Non-interactive users are a “special” type of user that does not interact with CRM via any CRM client. These are useful for programmatically accessing CRM, maybe for integration with an ERP system. (Such as Dynamics GP, NAV or AX.)

You can have a maximum of 5 non-interactive users.

Non-interactive users do not consume a license.

We change a user to be a non-interactive user within CRM, select the user and in the admin section change their access mode to “Non-interactive”. Other options include “Read-Write” (default) and “Administritive”.

5. To setup a non-interactive user, you first create a user with a license. Then edit their access mode to be non-interactive. Then return to Office 365 and remove the license as it is no longer required.

Import data in MS CRM

Below are the some of the interesting points about import data

1. You can import data into standard and customized attributes of most business and custom entities. You can also include related data, such as notes and attachments.
2. Microsoft Dynamics 365 includes a web application tool called Import Data Wizard. You use this tool to import data records from one or more comma-separated values (.csv), XML Spreadsheet 2003 (.xml), or text files.
3. By default, all custom entities are enabled for import. To determine if a business entity is enabled for import, see the entity metadata for the specific entity. If an entity is enabled for import, the entity metadata property IsImportable is set to true. The value of this property can’t be changed for the out-of-the-box business entities
4. A source file may contain data for one entity type or multiple entity types, such as accounts and contacts. For the source files that contain multiple entity data, you must provide a map that includes the <EntitiesPerFile> tag. Set the value of this tag to “Multiple” to indicate that there is more than one entity type in the source file
5. The first row in the source file should contain column headings. If you do not include headings, use the ImportFile.IsFirstRowHeader attribute to specify that the first row represents actual data. In this case, default column headings are created with the names Col1, Col2, and so on.
6. The first row in the source file should contain column headings. If you do not include headings, use the ImportFile.IsFirstRowHeader attribute to specify that the first row represents actual data. In this case, default column headings are created with the names Col1, Col2, and so on.
7. To create a note in Microsoft Dynamics 365, set the Annotation.IsDocument attribute in the annotation (note) entity to false. To create an attachment, set IsDocument to true.
8. If you do not provide mapping for an annotation (note) entity, the import job generates a default mapping for the note.
9. The maximum size of files that can be uploaded is determined by the Organization.MaxUploadFileSize property. This property is set in the Email tab of the System Settings in the Dynamics 365 application. This setting limits the size of files that can be attached to email messages, notes, and web resources. The default setting is 5 MB. However, an attachment size cannot exceed the maximum HTTP request size (the default is 16MB). For the change to take effect, reset Internet Information Services (IIS). To do this, click Start, click Run, type iisreset, and then click OK.
10. You cannot import data into the modifiedon, createdby, and modifiedby attributes. If you have to store data related to who created and modified the data and when the data was modified, you can create custom attributes in Microsoft Dynamics 365 and map the source columns to the new custom attributes.

Data Management in MS CRM

Below are the some of the interesting points about data management

1. Duplicate detection lets organizations set duplicate detection policies and create duplicate detection rules for business and custom entities.
2. You can clean the data by deleting, deactivating, or merging the duplicates reported by a duplicate detection job.
3. You can create multiple detection rules for the same entity type. However, you can publish a maximum of five duplicate detection rules per entity type at one time.
4.  A duplicate detection rule specifies a base entity type and a matching entity type. A duplicate rule condition specifies the name of a base attribute and the name of a matching attribute
5. The matching criteria consist of operators such as exactly match, first n-number of characters, or last n-number of characters.
6. You can clean the data by deleting, deactivating, or merging the duplicates reported by a duplicate detection job.

            Before running duplicate detection, enable it for each of the following:

• Globally (for all entities in the organization).
• For an entity.
• For specific operations.

7. If the caller (system user) of the RetrieveRequest message or the RetrieveMultipleRequest message doesn’t have Read privileges on some of the fields in the detected duplicate records, these records aren’t returned.

Document Management in MS CRM

Below are the some of the interesting points about document management:

1. The Microsoft Dynamics 365 administrator (a user who has the SharePoint Site Collection Administrator role) selects the Microsoft Dynamics 365 entities for which to enable the document management feature, and specifies the target SharePoint Server. As part of specifying the target server, the Microsoft Dynamics 365 administrator specifies the SharePoint Server site collection or the SharePoint Server site URL by using the SharePointSite entity
2. Creating and managing SharePoint document location records. Microsoft Dynamics 365 users can create and manage SharePoint Server document location records after SharePoint Server integration is enabled. You can create and manage SharePoint Server document location records by using the SharePointDocumentLocation entity. Microsoft Dynamics 365 also allows for the automatic creation of folders on the server that is running SharePoint Server for entity records under certain conditions. However, automatic creation of folders cannot be done through the Microsoft Dynamics 365 SDK.
3. Enable SharePoint integration:
• Client-to-server integration with SharePoint: The client-to-server integration is enabled by default. However, for a richer user experience, install the Microsoft Dynamics CRM List Component for Microsoft SharePoint Server 2010 or Microsoft SharePoint Server 2013. For more information about the component, see Microsoft Dynamics CRM list component for Microsoft SharePoint Server section later in this topic.
• Server-to-server integration with SharePoint: This does not require you to install the Microsoft Dynamics CRM List Component in SharePoint or any other additional software to have the SharePoint document management functionality within Dynamics 365. After you enable server-based SharePoint integration for your organization, you can’t revert to the client-based authentication method.

           Enable document management for entities: Select the entities in Microsoft Dynamics 365 for which you want to create and manage documents on SharePoint Server. When you enable document management for an entity in Microsoft Dynamics 365, a Documents link under the Common group in the left pane is added for the all entity records in the Microsoft Dynamics 365 web application. You can use the Documents link to create or manage SharePoint Server location records for the entity record.

   Specify the target SharePoint server: Specify the URL of a site or site collection on the SharePoint Online, SharePoint Server 2010, or SharePoint Server 2013. This URL is used to automatically create folders and document libraries on SharePoint.

4. Document management can be enabled for those entities in Microsoft Dynamics 365 that can be customized. By default, document management is enabled only for the following entities in a new installation of Dynamics 365:

S.No	Table
1	Account
2	KbArticle
3	Lead
4	Opportunity
5	Product
6	Quote
7	SalesLiterature

5. You must have the System Administrator or System Customizer role to enable or disable document management for an entity.

6. Validation Status (sharepoint_validationstatus)

Value	Label
1	Not Validated
2	In Progress
3	Invalid
4	Valid
5	Could not validate

7. Validation Status Reason (sharepoint_validationstatusreason)

Value	Label
1	This record's URL has not been validated.
2	This record's URL is valid.
3	This record's URL is not valid.
4	The URL schemes of Microsoft Dynamics 365 and SharePoint Server are different.
5	The URL could not be accessed because of Internet Explorer security settings.
6	Authentication failure.
7	Invalid certificates.

8. For server-based integration with SharePoint, Microsoft Dynamics 365 uses claims to authenticate and authorize Dynamics 365 users to access the documents stored in SharePoint
9. Dynamics 365 uses the following claims to integrate with SharePoint

Scenario	Claims
Dynamics 365 (online) and SharePoint Online	NameId (PUID) Both Dynamics 365 and SharePoint share Microsoft Azure Active Directory for user identity.
Dynamics 365 (online) and SharePoint on-premises	SMTP (email) No shared active directory infrastructure for user identity; claims sent as SMTP address. The claims is picked from WindowsLiveID field in Dynamics 365 and mapped to work email address from SharePoint.
Dynamics 365 on-premises and SharePoint Online	SMTP (email) No shared active directory infrastructure for user identity; claims sent as SMTP address. The claims is picked from PrimaryEmailAddess field in Dynamics 365 and mapped to work email address from SharePoint.
Dynamics 365 on-premises and SharePoint on-premises	Security Identifier (SID) Both Dynamics 365 and SharePoint share Microsoft Windows Server Active Directory for user identity.

10. You can use the UserMapping entity to specify custom claim mappings in Dynamics 365 to use a value other than the default value used by Dynamics 365 to authenticate and authorize Dynamics 365 users in SharePoint. For example, you can use the “last name” and “first name” of the user instead of “email” to authenticate Dynamics 365 users in SharePoint. Custom claim mappings override the default claim mappings used by Dynamics 365. You can define multiple custom claim mappings in Dynamics 365. By default, only users having the System Administrator role have access to the UserMapping entity.
11. By default, SharePoint supports the following claim types: NameId (PUID), SMTP (email), and UPN (user principal name). If you’re passing a claim of any other type, you must also create corresponding claim type mappings in SharePoint

Audit in MS CRM

Below are the some of the interesting points about auditing:

Below are the some of the interesting points about auditing:

1. Auditing is supported on all custom and most customizable entities and attributes

2. Auditing is not supported on metadata changes, retrieve operations, export operations, or during authentication

3. Supported for auditing

Audit of customizable entities

Audit of custom entities

Configure entities for audit

Configure attributes for audit

Privilege-based audit trail viewing

Privilege-based audit summary viewing

Audit log deletion for a partitioned SQL database

Audit log deletion for a non-partitioned SQL database

Microsoft Dynamics Dynamics 365 SDK programming support

Audit of record create, update, and delete operations

Audit of relationships (1:N, N:N)

Audit of audit events

Audit of user access

Adherence to regulatory standards

4. Non supported for auditing

Audit of read operations

Audit of metadata changes

Audit of text blobs, notes, and attachments

5. You can enable or disable auditing at the organization, entity, and attribute levels. If auditing is not enabled at the organization level, auditing of entities and attributes, even if it is enabled, does not occur. By default, auditing is enabled on all auditable entity attributes, but is disabled at the entity and organization level.
6. For Microsoft Dynamics 365 servers that use Microsoft SQL Server Enterprise editions, auditing data is recorded over time (quarterly) in partitions. A partition is called an audit log in the Microsoft Dynamics 365 web application. Partitions are not supported, and therefore, not used, on a Microsoft Dynamics 365 server that is running Microsoft SQL Server, Standard edition.
7. The ability to retrieve and display the audit history is restricted to users who have certain security privileges: View Audit History, and View Audit Summary. There are also privileges specific to partitions: View Audit Partitions, and Delete Audit Partitions. See the specific message request documentation for information about the required privileges for each message.
8. Audited data changes are stored in records of the audit entity.
9. Data that can be audited:
• Create, update, and delete operations on records.
• Changes to the shared privileges of a record.
• N:N association or disassociation of records.
• Changes to security roles.
• Audit changes at the entity, attribute, and organization level. For example, enabling audit on an entity.
• Deletion of audit logs.
• When (date/time) a user accesses Microsoft Dynamics 365 data, for how long, and from what client.
10. Enabling or disabling of field level security by setting the IsSecured attribute cannot be audited
11. For attribute auditing to take place, auditing must be enabled at the attribute, entity, and organization levels
12. A user must be assigned the System Administrator or System Customizer role to enable or disable auditing
13. when enabling auditing on an entity, all of the entity’s attributes are enabled for auditing by default. Of course you can explicitly disable auditing on any or all of the attributes as needed
14. Fully Customizable entities:

Account	Campaign	CampaignActivity	CampaignResponse	Competitor	Connection
Contact	Contract	Email	Fax	Goal	Incident
Invoice	InvoiceDetail	Lead	Letter	List	Opportunity
OpportunityProduct	PhoneCall	Product	QueueItem	Quote	QuoteDetail
SalesLiterature	SalesOrder	SalesOrderDetail	ServiceAppointment	SystemUser	Task
Territory

15. Entities we cannnot audit:

ActivityPointer

Annotation

BulkOperation

Calendar

CalendarRule

CustomerOpportunityRole

Discount

DiscountType

IncidentResolution

KbArticle

KbArticleComment

KbArticleTemplate

Notification

OpportunityClose

OrderClose

ProductPriceLevel

QuoteClose

RecurrenceRule

Resource

ResourceGroup

ResourceGroupExpansion

ResourceSpec

SalesLiteratureItem

SalesProcessInstance

Service

Subject

Template

UoM

UoMSchedule

Workflow

WorkflowLog

16. If your Microsoft Dynamics 365 server uses Microsoft SQL Server standard edition, which does not support the database partitioning feature, the DeleteAuditDataRequest request deletes all audit records created up to the end date specified in the EndDate property.
17. If your Microsoft Dynamics 365 server uses an Enterprise edition of Microsoft SQL Server that does support partitioning, the DeleteAuditDataRequest request will delete all audit data in those partitions where the end date is before the date specified in the EndDate property. Any empty partitions are also deleted. However, neither the current (active) partition nor the audit records in that active partition can be deleted by using this request or any other request.
18. New partitions are automatically created by the Microsoft Dynamics 365 platform on a quarterly basis each year. This functionality is non-configurable and cannot be changed
19. Microsoft Dynamics 365 (online & on-premises) support the ability to audit user access. The information that is recorded includes when the user started accessing Microsoft Dynamics 365 and if access originated from the Microsoft Dynamics 365 web application, Dynamics 365 for Outlook, or SDK calls to the web services.
20. To enable or disable user access auditing, you must retrieve the target organization’s record, and update the Organization.IsUserAccessAuditEnabled attribute value for the organization. Global auditing on the organization must also be enabled by setting the Organization.IsAuditEnabled attribute to true in the organization record. To audit the origin of user access, for example: web application, Dynamics 365 for Outlook or SDK, you must enable auditing on the entities being accessed.

Maximum rollup fields in MS CRM

You are limited to a maximum of 10 Rollup fields per Entity and a Maximum of 100 per organization.  On Premise deployments can modify this but online cannot.  A roll up field cannot include other rollups.

Two more interesting points on Rollup fields:

1. Rollup fields cannot be audited.
2. Rollup fields can include hierarchy data.

What is fetchXML?

FetchXML is proprietary query language used in Microsodt Dynamics CRM online or on-premises to retrieve records from an entity. It is depends on schema language. In terms of capabilities it is equal to queryexpression,  and it has addition feature of save query as user-owned saved view in userQuery system entity and and as an organization-owned saved view in the savedquery entity.

We will run FetchXML and retrieve records using RetrieveMultiple method by creating FetchExpression object.

Below is the sample code on running fetchXML.

String fetchXML=@"<fetch mapping='logical'>

   <entity name='account'>

      <attribute name='accountid'/>

      <attribute name='name'/>

</entity>

</fetch>";

FetchExpression fetchExpression=new FetchExpression(fetchXML);

EntityCollection entityCollection=service.RetrieveMultiple(fetchExpression);

Note: Don’t retrieve all attributes in a query because of the negative effect on performance. This is particularly true if the query is used as a parameter to an update request. In an update, if all attributes are included this sets all field values, even if they are unchanged, and often triggers cascaded updates to child records.