MSD 365 CRM Activity entities An activity can

MSD 365 CRM

Activity entities • An activity can be thought of as any action for which an entry can be made on a calendar. An activity has time dimensions (start time, stop time, due date, and duration) that help determine when the action occurred or will occur. • Activity entities can only be owned by a user or team, they can’t be owned by an organization. • In Dynamics 365, a user with a specific security role has the same set of privileges to all system and custom activities. You can’t add or remove privileges for individual activities. For example, you can’t give a user the Delete privilege to the system activity, such as Task, and not give the Delete privilege to the custom activities. However, you can give a user different privileges to individual system or custom entities.

Business rules • There is a limit of 10 if-else conditions on business rules. Workflow • When a background workflow is configured as an on-demand process the actions that the workflow can perform are limited to those the user could perform based on the privileges and access levels defined by the security role(s) set for their user account.

Dialogs can be deleted but you will need to deactivate them first. As you cannot delete an active dialog. Business Process Flows Benefits include • Consistency • Condition branching to enforce business best practice • Easy customization to tailor them to specific organizational need • Direction based conditions, meaning that one business process flow can span multiple record types. For example, when a lead becomes an opportunity. § Each business process flow will have a primary entity. If an entity is to be used within a business process flow as a primary or “secondary” entity it must be enabled for business process flows. § Once set you can NOT turn off business process flows. But having said that, just because an entity is enabled for business process flows doesn’t mean you have to use them with it! § You can edit a business process flow that is active!

Business Process Flows § It is possible for one entity to have multiple business process flows. The sequence that the process flows are presented to a user is governed by selecting the Order Process Flow option. § There can be no more than 10 active business process flows per entity. § Each process can contain no more than 30 stages. § Multi-entity processes can contain no more than 5 entities. Auditing § The activity entity can’t be audited but individual activity types such as phone call, appointment (etc. ) can be. § Auditing is not supported for read operations § Auditing is not supported for metadata changes § Auditing is not supported for text blobs, notes and attachments.

Document management • Two architectures exist for Share. Point integration. Client-side integration typically used in an on premise scenario requiring the installation of a Share. Point list component. Or server based Share. Point integration which doesn’t require the list component. Server-based integration is the recommended approach whenever possible. • Share. Point folders - Multiple folder locations can exist for an individual record. And a single location can be shared between two records. • Once the setup has been completed, on any of the enabled entities a document section will exist in the navigation. From here you can view and associate documents with that entity. • It is possible to delete a document that is uploaded to Share. Point via MSD. Doing so removes the document from Dynamics 365 and Share. Point. But if you delete the Dynamics 365 record then the documents would remain in Share. Point. • If two records are merged their document location information is merged. This doesn’t mean the that Share. Point documents are moved or duplicated. Just that the newly merged Dynamics 365 record will point to both Share. Point locations.

Data management • Once the duplicate detection rule has been created, if a user creates a potential duplicate a warning message will be given. Clicking save would continue with the creation of the duplicate, or clicking cancel will allow them to make any required changes. • Data maps - When we import data the details can be stored as a data map. This is a useful option if the import needs to be repeated multiple times, as any mapping of columns can be saved and re-used. • Data encryption - Microsoft Dynamics 365 uses standard Microsoft SQL Server cell level encryption for a set of default entity attributes that contain sensitive information, such as user names and email passwords. This feature can help organizations meet FIPS 140 -2 compliance. For Microsoft Dynamics 365 (online) and Dynamics 365 (on-premises), all new and upgraded organizations use data encryption by default. Data encryption can’t be turned off. • One note integration - From the social pane in CRM it is possible to open One. Note notebooks in the context of the currently selected record. You can then create and collaborate on One. Note documents using any of the supported clients. One. Note integration uses Share. Point to store the notebooks. So you need to enable that before using One. Note. This is because your One. Note notebooks will reside in Share. Point to make them accessible to all users. If you remove a CRM record the associated One. Note notebook will not be removed from Share. Point. If this needs to be removed it will need to be manually deleted from Share. Point. By default, CRM will create a separate document location and a separate One. Note notebook for each record viewed.

Dynamics security Business Units • • • The root business can be renamed. The root business unit cannot be deleted or disabled. The root business unit cannot be moved to have a parent business unit. The name of the root business unit will default to the organization name when the system is first deployed. All child business units have a parent which will either be another child or the root business unit. Meaning the root business unit is always the top of the business unit hierarchy. • The parent business unit on a new business unit will always default to the root but can be changed. • The definition of business units often follows the companies organizational structure but this is not essential. Ideally the business unit structure should mirror whatever is needed to support the security requirements of an organization. • Child business units can be renamed. • Child business units can be disabled. • Child business units can be deleted but only after being disabled. • Any users in a business unit will lose access to the application if the business unit they are assigned to is disabled. • Child business units can be moved under a new parent – If you move the business unit users will move with the business unit.

Dynamics security Users • With online, when we create a user and assign a license in Office 365 the user is created in Dynamics 365. However at this point the user cannot login into Dynamics 365 as they must also have a role assigned. The exception to this is when a license is assigned to a Global Admin in Office 365. As they will be automatically given System Administration access in Dynamics 365. • Users cannot be deleted, however they can be disabled. • If you move a user from one business unit to another their security roles will be removed. So having completed the move, new security roles will need to be added before they can access CRM again. Business units & Teams • Each business unit has a default team. This is a “special” team that cannot be removed. Users are automatically added as they are assigned to the business unit. Teams • Two types – a) Owner team - Owner teams are associated with a business unit. As they will need to be assigned a security role from that business unit. But the members of the team do not have to belong to the same business unit. This is useful when a group of people need to collaborate across business units. b) Access team - a special type of team giving record sharing capabilities. “User created” access teams do not have roles and cannot own records. Although records can be shared with them without the need of the team owning the record. “Auto-Created” Access teams are used to share individual records.

Dynamics security Teams • Before you can use an access teams on an entity it must be enabled for access teams. To do this you will need to use the customizations option in CRM. • Having enabled the entity for access teams you will need to create an access team template. Access team templates are defined in security settings in Dynamics 365. • You are limited to 2 team templates per entity. • Roles can be assigned to owner teams or users. When a user is part of an owner team they inherit the permissions granted by the role on the team. Consider this, as adding a user to a team effectively gives them a role.

Dynamics security

Dynamics security • Entities which can be user owned support all of these variations but organization owned entities will either be a red circle or sold green dot. Simply as the other options don’t apply to them. (You either have access to an organization owned entity or you don’t!) Teams and Security roles • Roles can be assigned to owner teams. (Roles can’t be assigned to access teams. ) • A security role MUST be assigned to an owner team for it to own records. • A team always links to one business unit. • Team members can belong to any business unit. • Heritance of security permissions works across users and teams. Meaning the privileges from roles assigned to the user are combined with roles assigned to teams the user is a member of. (Granting them the least restrictive access level. ) • It is possible to have two security roles with the same name. Each role could be linked to a different business unit and could give users in each business unit differing levels of access. You need to be aware of this as it could appear confusing! • Just like with users, if you change the business unit on a team the security roles associated with the team are removed.

Hierarchy security • When you first set-up hierarchy security it must be enabled. This is done in the Hierarchy Security option found in the security area of settings. • Once enabled you opt to use this approach based on the manager hierarchy (as defined on the CRM users) or based on custom position hierarchy. • Next you define how deep the hierarchy should go. A manager will have Create, Read, Update and Delete access to their direct reports. But then this depth option is used to decide how many layers below that they can see. (Note: See as they only have read access as they go deeper in the hierarchy). • Finally, we select which entities this should apply to. By default, the hierarchy security model applies to all entities. But you can opt to exclude entities.

Themes • Themes allow you to create a custom look to your Dynamics 365 solution. • The themes option is available in the customization area of settings. • A theme doesn’t take effect until it is published. You can only have one default theme. And the default theme is the currently published theme. Meaning several themes can be defined but only one is active at any moment in time. • Themes cannot be included in your solution. Meaning they are not portable between organizations.

Email integration Some common uses of email integration include - • Outbound emails from Dynamics 365. Either sent directly from Dynamics 365 users to contacts, accounts (etc) or automatically via workflow. • Updating contacts, appointments and tasks between Dynamics 365 and Outlook. • Inbound emails into Dynamics 365, including automatically taking emails into queues. (e. g. support emails into a support queue. ) • Record creation rules to convert inbound emails into Dynamics 365 entities. Such as creating a case from an inbound email. • Tracking of emails from Outlook into Dynamics 365. (For example sales “conversations” tracked against an opportunity. ) • Support for mobile devices.

Email synchronizing options There are several options for integrating email with Dynamics 365 including • Dynamics 365 for Outlook • Server-side synchronization (The recommended approach) • Email router (Important Note: Deprecated from December 2016 Update onwards. ) For Dynamics 365 on-line / office 365, Server-side synchronization is the recommended approach. It allows Dynamics 365 and Exchange to communicate with no additional client software or server processes. Serverside synchronization is a required component if you wish to enable the email folder tracking feature. If you use Dynamics 365 for Outlook for email integration users are required to be logged into Outlook for sending / receiving emails. However, server-side sync does not require this. As the name suggests, all of the processing is done on the server meaning the user does not have to be connected to a client. Note: Even when using server-side sync you can still opt to use the Dynamics 365 for Outlook client as it provides access to all Dynamics 365 data within Outlook.

Server side synchronization To track emails AND synchronize appointments five configurations are supported for server-side sync. Those are - • Connect Dynamics 365 (online) to Exchange Online • Connect Dynamics 365 (online) to Exchange Server (on-premises) • Connect Dynamics 365 (on-premises) to Exchange Online • Connect Dynamics 365 to POP 3/SMTP servers

Server side synchronization

Server side synchronization Three steps are involved in configuring server-side synchronization- • Configure system settings. • Configure the server profile. • Define and configure mailboxes for users / queues. Notice that the synchronization method on the mailbox can be set for “incoming email”, “outgoing email” and “appointments, contacts and tasks”. For example, incoming email might be handled by the email router, whilst appointments remain on Microsoft Dynamics for Outlook. Also, importantly the method can be set to none. Say you wanted to block all outgoing mail from a particular mailbox that could be done.

Folder tracking • You can only track folders or subfolders inside your Exchange Inbox. Only the folder you select will be tracked. For example, if you select a folder that includes subfolders, the subfolders aren’t tracked unless you specifically select them in this dialog box. • The maximum number of folders you can track is 25.

Entities • The entity name cannot be changed, and will be prefixed with the publisher prefix. • Display name and plural name can be changed. • Ownership can be “User or Team” or Organization. Once set it cannot be changed. • You can optionally enable entities for the interactive service hub and you can disable this option if required. By default an custom entities are not enabled for the interactive service hub. • Each entity can be given a color; all custom entities will default to green. But this can be changed. • All entities will have a primary field, called “name” by default but this can be changed. The primary field can only have a type of “Single Line of Text”. It will default to a length of 100 but this can be changed. (Note: The primary field is not the database primary key; it does not have to include a unique value. Behind the scenes each record has a GUID which is an automatically created primary key. ) • On creation entities can be defined as being an activity entity. Custom activity entities can optionally be displayed in the activity menus. All activity entities will be by implication User or Team owned. All activities share a common set of privileges.

Entities • Having saved an entity, the following properties are read-only, meaning they can only be defined as you create an entity, • Name • Ownership • Define as an activity entity • Display in activity menus • Once enabled on an entity the following properties cannot be disabled; • Business process flows • Feedback • Notes • Activities • Connections • Sending email • Queues • Notes, activities and connections are enabled by default when a custom entity is created. But they can be disabled on create. • An entity can be shown in none, one or multiple areas in CRM. Out of the box the areas include sales, service, marketing, settings and help center. You can only change this option for custom entities it is not possible to change the display area for system entities. • Document management, access teams, allowing quick create are all examples of properties that can be turned on and off. • Enable for mobile, allows you enable the entity for mobile and if you require mobile offline. Plus you can configure download filters to drive how much data will be available offline.

Entities • Properties are grouped under several headings; these include Process – allows enabling an entity for business processes. Communication & Collaboration – Collaboration options include sending emails, access teams, queues etc. Data Services – data featuring include auditing and duplicate detection etc. Outlook & Mobile – Allows an entity to be enabled for mobile and phone access. Help Deleting entities • You cannot delete system entities. (Although you can “hide” them by creative use of security roles or amendments to the site map. ) • Custom entities can be deleted. • You cannot delete a custom entity if other entities have dependencies on it. For example, a look up to that entity. You would need to remove the dependencies before attempting the delete! • If the entity you wish to remove is part of a managed solution you will not be able to remove it directly. You would need to remove the entire managed solution. • When we remove an entity its definition is removed along with all the data records.

Fields Three types • Simple, these are “normal” fields that contain data not based on any formula. Examples include test, option sets, whole numbers etc. • Calculated, contain calculations to derive their content. (Calculated from other fields on the current or related parent entities. ) • Rollup, these fields contain a aggregated value computed from the related records. q Whenever a currency field is added you will also have a currency lookup. This is created automatically and is called transactioncurrencyid. Plus you get two values, the currency amount and a base amount. Also read https: //neilparkhurst. com/2017/05/22/mb 2 -716 -customizing-and-configuration-fields/ Calculated fields • A calculated field, as the name suggests, is simply a field which is derived from a calculation. The calculations can include conditions and make use of fields on the current entity and related parent entity. They can work with number fields but also date calculations and string manipulation are possible. • Because the field type cannot be changed it is therefore not possible to convert simple fields to calculated.

Calculated fields • However the formula behind the calculated field can be changed at any point. • Calculated fields are set when the record is saved. NOT when the data is entered. The calculated value is also set when a form is opened or a value viewed in a list view. • A calculated field can include other calculated fields. Rollup fields • When you create a new roll up field a process will run to roll them up 12 hours after the field is created. After that a system job will be fired every hour to keep them up-to-date. • Calculation of a rollup Field is a recurring job. The administrator can change the timing and frequency of the recurring jobs used to roll up fields. • Rollup fields are not available on many to many (N: N) relationships. • Calculated fields cannot be included in the rollup calculation.

Rollup fields • The roll up field has a status; this is general not required but is useful if you get unexpected results. The possible values of the status field are shown below.

Rollup fields Some considerations to be aware of are listed below • When you manually refresh a field the maximum number of records considered for rollup is 50, 000. If you exceed this when rolling up manually an error will be given. However this limit does not apply when the automated system job is used to calculated the rollup value. • You can define a maximum of 100 rollup fields for the entire organization • You can define a maximum of 10 rollup fields per entity. • A workflow wait condition cannot use a rollup field. • You cannot rollup a rollup field. • A rollup cannot reference a calculated field that references another calculated field. • The rollup can only apply filters to the source entity or related entities simple fields or non-complex calculated fields. • Rollup fields do not support many to many (N: N) relationships. • Business rules and workflows always use the last calculated value of the rollup field. • The rollup happens under the system user context. Meaning all users see the same rollup field value, regardless of security roll. • If the precision of the aggregated field is greater than the precision of the rollup field, the aggregated field precision is rounded down to the precision of the rollup field, before the aggregation is performed. • Rollup field aggregation uses only direct relationships explicitly defined in the rollup field definition, no other relationships are considered.

Rollup fields https: //neilparkhurst. com/2016/08/06/dynamics-crm-rolled-up-fields-and-hierarchical-relationships/ Primary field • All CRM entities have a primary field and it is often called “name”, although that is just the default setting and can be changed. • The primary field is not a key field! It is simply a field that is mandatory on all records. Primary key • All Dynamics 365 entities have a special field that is “hidden” on forms that is the id field for that entity. This id field holds the GUID value (primary key) for the record. • The GUID unique not just within the entity but across the entire database. • All entries in the Dynamics 365 database have a GUID. (Including meta data, so every entity, form, view, dashboard (etc. ) has a GUID. ) Alternate keys • You can have up to 5 alternate keys per entity. • When an alternate key is created, the status is initially pending. The status changes to active once Dynamics 365 has been able to create any required unique indexes. This points to another benefit of alternate keys as their presence can improve record lookup times. • Like the GUID, this key field doesn’t show on Dynamics 365 forms etc.

Option sets • You do need to be mindful of deletions! (On local and global option sets. ) If the option is currently being used the existing records will not actually be changed. But when you view them they are going to show as blank as the option no longer exists. And you won’t be able to use Advanced Find to locate them as once deleted you wouldn’t be able to select the old option in your search criteria. Therefore if you do need to delete an option set item it is good practice to update the existing data prior to removal of the option. Field security • Field-level security can be applied to system and custom fields across the system. And by default is disabled for all fields. • It is important to realize that field-level security does not apply to just Dynamics 365 forms but everywhere you might see or maintain data. For example, a view may display a field as blank; this isn’t because the field contains no data! It is because the current user doesn’t have read privilege on this field. • To grant access to fields which are enabled for field-level security you need to create a field security profile. This is done from the “Field Security Profiles” option which can be found in the security area of settings. Relationships Relationship types include • One to Many (1: N) or Many to One (N: 1) • Many to Many (N: N) • Hierarchical Relationships (e. g. Account and sub accounts. ) • Connections • Customer

Relationships • There is no such thing as a one to one 1: 1 relationship! • With a 1 to many relationship, the child record will have a lookup field that contains the GUID of the parent. A contact for example will have a look up to the account entity. • With a many to many relationships the parent can have multiple children and the child can have multiple parents. One example of this might be competitors and opportunities. As there might be multiple competitors on one opportunity. And each competitor can exist on multiple opportunities. • “Customer” has been a special polymorphic relationship. For example, consider the customer field on cases. It is polymorphic because a customer could be an account or contact, so we can have one field that can relate to either entity. This relationship always existed in older versions of “CRM” but it wasn’t until CRM 2016 Update 1 that customizers could create customer fields on any entity. It is now possible to create a customer field on any entity. • Creating a native many to many relationship is actually very similar to creating a one to many relationship. Except the many to many relationship does NOT have any cascading rules. • A hierarchical relationship is used to reflect how one record in an entity relates to another. A good out of the box example of this might be how accounts can have parent accounts. • Hierarchical relationships are self-referential one-to-many relationships. (Self-referential as the account has a parent account. )

Relationships • Connections are essentially a special relationship that allows us to link records in a “non-traditional” manner based on a connection role. Traditional relationships are “hard” relationships, such as linking a case to a contact. Connections are useful to record “soft” relationships, such “is a friend of”, “former employee of”, “went to school with” etc. • Once an entity has been enabled for connections this property cannot be disabled. • Before we can connect anything we need to define the possible connect roles. Luckily out of the box Dynamics 365 ships with many pre-created connection roles. So often a role will already exist. • To access the connection roles (and create your own) use the connection roles option that can be found in the business management area of settings. Entity Mapping • Entity mapping is an “extension” to relationships that allows us to map fields. This can be really useful when creating new related records. Consider the process for creating a new contact related to the account. When we do this there are lots of fields that could be usefully defaulted on the new contact. (Including things like phone number and address. ) • An important concept with entity mapping is that the mapping only applies when new records are created directly from the parent. • Mapping is NOT designed to keep the fields synchronized it simply defaults them when new records are created. Meaning mapping is never applied on the update of records. • It is possible to map one field on the parent entity to multiple fields on the child entity. When you map a field the data types must match.

Entity Mapping Possible errors in entity mapping – • The data type must match – meaning single line to text to single line of test. Or currency to currency etc. • The length of the target field cannot be shorter than the source field – meaning you can’t map a text field that is 100 characters long to a field that is 10 long. (But you could map one that is 10 long to one that is 100 long!) • The format should match – text fields (for example) can have formatting. As they can hold phone numbers, urls, email addresses etc. Any formatting options must be the same on the source and target fields. • The target field must not be used in another mapping – We can map one source field to multiple targets. But each target can only exist once. • The source field must be visible on the entity form – meaning to map phone number from the account to the contact, phone number must show on the account form. • The target field must be a field a user can enter data into – See note below! • Address ID values cannot be mapped – you can map individual address fields but you cannot map the address ID field. (An internal GUID used to hold addresses. )

Entity Mapping Note : I wanted to review what was implied by the comment “target field must be a field a user can enter data into”. So I did some testing! I thought of three combinations which could come into play here - § The field is read-only on the form … in this circumstance the mapping applied and the child record was correctly saved with the field populated. § The field is not on the form … in this circumstance the mapping applied and the child record was correct saved with the field populated. § The field is restricted using field security profile …. If you map something into a field but you don’t have the security privilege to create that field an error will be given.

Business Process Flows § There can be no more than 10 active business process flows per entity. § Each process can contain no more than 30 stages. § Multi-entity processes can contain no more than 5 entities. Access teams § You are limited to 2 team templates per entity. Folder tracking § The maximum number of folders you can track is 25. Rollup fields § You can define a maximum of 100 rollup fields for the entire organization § You can define a maximum of 10 rollup fields per entity. Alternate keys § You can have up to 5 alternate keys per entity. Business rules § There is a limit of 10 if-else conditions on business rules.