Issues with tracking Email in MS CRM from Shared Mailbox through outlook client

Manage Dynamics CRM with Multiple Synchronized Email Accounts

In today’s business landscape, technology is ever-changing and moves quickly. It is not uncommon for an individual to conduct business using many different email accounts. The synchronization of the Microsoft Dynamics CRM client for Outlook allows one synchronizing email account per CRM user – which means a user can track only what is in the primary email account and nothing else. How, then, does one track emails from various email accounts? By combining your email accounts into a single inbox via Outlook rule settings. The Outlook rule settings will allow you to automatically move email from one inbox to your primary inbox, and as a result, track those emails into CRM.

Other Proposed Solutions

There have been previous posts regarding shared mailbox from Outlook to track, however none are specific in Outlook that you can track from a shared mailbox. Microsoft saw this as a security so not multiple people can access a mailbox to track in CRM without licenses per user.

1) Generate a Queue in CRM to the shared mailbox and ensure that is email router and store all the emails into CRM.
Adv – CRM stores all emails incoming
Disadv – you can not select which ones are being stored in the CRM, unless you delete

2) You could do forward mailbox by sending the mail into each member’s inbox
Adv – You skip a step of dragging the single email
Disadv – makes your personal inbox have more emails

3) Continue with the extra step of dragging the single email to your primary inbox, due to the outlook app only recognizes the CRM user at the default e-mail address.
Adv – you know exactly what you want into CRM
Disadv – extra step of dragging email

Dynamics CRM 2015 for Outlook: Diverse Error messages


This article is to show examples and explain further into diverse error messages appear during the start-up process of Outlook, when using CRM 2015 for Outlook client.

An error occurred promoting this item to Microsoft Dynamics CRM” 



“An error occurred promoting this item to Microsoft Dynamics CRM.Item Name=”


“Only items in the default Microsoft outlook store can be promoted to Microsoft Dynamics CRM”


The below shows how to create the Outlook views for being able to identify the Outlook items which are causing the error messages mentioned at the beginning of this article. Using this outlook view, you will be able to identify those Outlook items with have the above mentioned CRM MAPI object property crmLinkState values.

1. Open the Outlook application with Microsoft Dynamics CRM Client for Outlook Configured. Click on the File option at the top Left corner


2. Now select Options from the File drop down.


3. Select Customize the Ribbon and check the Developer option, then click on OK.


4. Get back to the main page of Outlook and open any email that is tracked successfully. In the email window, click on Developer Tab and choose “Design this form”.


5. On clicking the “Design This Form” option, the page will display the fields on the form with the view set as “User-defined fields in this item”. Here you will find the “crmLinkState” field and since it is tracked successfully it is set to 2. (1 (WillBeLinked), 3 (WillBeUnlinked), 0 Unlinked and 4 (WillBeUnlinkedAndDeleted).)


6. If there isn’t a field by the name “crmLinkState” in any of the views of Select Item, then create one by the same name and Type as Number.


7. Click on Publish and select Publish Form As.


8. Now enter a name for the Form as “CRM Debug Form” and then click on Publish.


9. Once done, get back to the Main Outlook page and click on the Search Bar, then click on the + More icon.


10. In the + More drop down select crmLinkState.


11. Once selected the “crmLinkState” field, we will receive the field under the search bar along with an option to enter the Link State i.e. either 1, 3, 4.


12. Open the emails displayed below and Untrack them.


13. In this way we will have to Untrack all the emails with crmLinkState 1, 3, 4 and we will never receive the error pop up “An error occurred while promoting this item to Microsoft Dynamics CRM” and “An error occurred while promoting this item to Microsoft Dynamics CRM.Item Name=”

Please Note:

The search functionality of Outlook is limited; you will have to search each folder individually to identify those MAPI objects we were speaking about previously. If you would select search in all folders of Outlook or the mailbox, this won’t work, you will have to run this search query folder by folder.

After you identify the items, you will need to find them in Outlook and untrack them ( set the crmLinkState to 0). 
An alternative way to identify the affected outlook items is using MFCMAPI or other MAPI property viewing tools:

The below property of the store taken from MFCMAPI

<property tag = “0x3400000B” type = “PT_BOOLEAN” > 
<ExactNames>PR_DEFAULT_STORE, PidTagDefaultStore</ExactNames> 

In this scenario, users might have shared mailboxes, other mailboxes then the default mailbox of the Outlook Profile or PST files where they were trying to track emails into CRM. When looking for the emails with a crmLinkState value of 1,3, or 4 you will need to check each folder of the mailboxes one by one as the search performed on the mailbox itself might not yield any result.

This is not the end you need to make this form as a default form for your mail box. I need to check that else every time you need to choose your custom form.


Leave a comment

Filed under Dynamic 365, MS CRM

CRM Tips: Print a CRM record

To print a record in Microsoft Dynamics CRM web client

  1. Click the gear in the upper right hand corner by your name
  2. Click “Print Preview”

To print a record in Microsoft Dynamics CRM Outlook client

  1. Select the record from a view
  2. Click File->Print in Outlook

Leave a comment

Filed under Uncategorized

Security Model – Microsoft Dynamics 365


Microsoft Dynamics 365 and Microsoft Dynamics 365 (online) provide a security model that protects data integrity and privacy, and supports efficient data access and collaboration.

The goals of the model are as follows:

  1. Provide users with the access only to the appropriate levels of information that is required to do their jobs.
  2. Categorize users by role and restrict access based on those roles.
  3. Support data sharing so that users and teams can be granted access to records that they do not own for a specified collaborative effort.
  4. Prevent a user’s access to records the user does not own or share.

Role Based Security: focuses on grouping a set of privileges together that describe the responsibility for a user.

Record Based Security: Focuses on access rights to specific records

Field Level Security: Restrict access to specific high business impact fields in an entity only to specified user or teams.

Hierarchy Security: Enables you to model the manager/direct report structure that is often used in businesses. The Position entity provides the capability to model this type of relationship. A system user in a higher-level position can access the business data being accessed by another user in a lower level position.

Role based security can be used to control access to entities

Role contains privilege that defines a set of actions that can be performed within the organization. All users must be assigned to one or more predefined or custom roles. Roles can also be assigned to teams. When a user or team is assigned to one of these roles, the person or team members are assigned the set of privileges associated with that role. A user must be assigned to at least one role. Microsoft Dynamics 365 includes 14 predefined roles.

A privilege authorizes the user to perform a specific action on a specific entity type.  In Microsoft Dynamics 365, there are over 580 privileges that are predefined system-wide during setup. Privileges apply to an entire class of objects, rather than individual instances of objects. A privilege contains an access level that determines the levels within the organization to which a privilege applies. Each privilege can have up to four access levels: Basic, Local, Deep, and Global.

Global. This access level gives a user access to all records within the organization, regardless of the business unit hierarchical level to which the instance or the user belongs. Users who have Global access automatically have Deep, Local, and Basic access, also. The application refers to this access level as Organization.

Deep. This access level gives a user access to records in the user’s business unit and all business units subordinate to the user’s business unit. Users who have Deep access automatically have Local and Basic access, also. The application refers to this access level as Parent: Child Business Units.

Local. This access level gives a user access to records in the user’s business unit. Users who have Local access automatically have Basic access, also. The application refers to this access level as Business Unit.

Basic. This access level gives a user access to records he or she owns, objects that are shared with the user, and objects that are shared with a team of which the user is a member. The application refers to this access level as User.

None. No access is allowed.

Putting it all together

  • If a user has the Deep Read Account privilege, this user can read all accounts in his or her business unit, and all accounts in any child business unit of that business unit.
  • If a user has Local Read Account privileges, this user can read all accounts in the local business unit.
  • If a user is assigned the Basic Read Account privilege, this user can read only the accounts that he or she owns or the accounts that are shared with him or her.
  • A customer service representative with the Basic Read Account privilege can view accounts that he or she owns and any accounts another user has shared with this user. This makes it possible for the representative to read the account data that is relevant to a service request, but not to change the data.
  • A data analyst with the Local Read Account privilege can view account data and run account-related reports for all accounts in his or her business unit.
  • A finance officer for the company with the Deep Read Account privilege can view account data and run account-related reports for all accounts in his or her business unit and accounts in any child business unit.

List of predefined security roles

Role Description
CEO-Business Manager A user who manages the organization at the corporate business level.
CSR Manager A user who manages customer service activities at the local or team level.
Customer Service Representative (CSR) A customer service representative (CSR) at any level.
Delegate A user who is allowed to act on behalf of another user.
Marketing Manager A user who manages marketing activities at the local or team level.
Marketing Professional A user engaged in marketing activities at any level.
Sales Manager A user who manages sales activities at the local or team level.
Salesperson A salesperson at any level.
Schedule Manager A user who schedules appointments for services.
Scheduler A user who manages services, required resources, and working hours.
Support User A user who is a customer support engineer.
System Administrator A user who defines and implements the process at any level.
System Customizer A user who customizes Microsoft Dynamics 365 entities, attributes, relationships, and forms.
Vice President of Marketing A user who manages marketing activities at the business unit level.
Vice President of Sales A user who manages the sales organization at the business unit level.

Record Based Security: 

It 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.

Access rights

An access right is granted to a user for a particular record.

Read: Controls whether the user can read a record.
Write: Controls whether the user can update a record.
Assign: Controls whether the user can assign a record to another user.
Append: 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 Append To access right on the case for the operation to work.
Append To: Controls whether the user can append the record in question to another record.
Share: 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: Controls whether the user can delete a record.

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.

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.

Share. Any user who has share privileges on a given entity type can share records of that type with any other user or team.

Sharing and inheritance: 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.

Assigning records: 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.


Field-level security:

Used to restrict access to high business impact fields to specific users and teams. For example, you use this to enable only certain users to read or update the credit score for a customer. For this release, field-level security can be applied to both custom fields and many out-of-box (OOB) fields.

The following steps describe how to restrict access to a field:

  1. Enable field-level security for an attribute
  2. Create a field-level security profile
  3. Associate users or teams with the profile
  4. Add specific field permissions, such as Create, Update or Read for a specific attribute to the profile

Role-based security lets you see a specific entity type, record-based security lets you see individual records, and field-level security lets you see specific fields.

Hierarchy Security Model: The hierarchy security model is an extension to the existing Microsoft Dynamics 365 security models that use business units, security roles, sharing, and teams. It can be used in conjunction with all other existing security models. The hierarchy security offers a more granular access to records for an organization and helps to bring the maintenance costs down. For example, in complex scenarios, you can start with creating several business units and then add the hierarchy security. This will achieve a more granular access to data with far less maintenance costs that a large number of business units may require.



Leave a comment

Filed under Uncategorized

MS CRM – Run Workflow / Process When Merging Records


When records are merged, an entry should appear in the ACTIVITIES panel. It should show who merged the records so that follow-up can be made if records were merged incorrectly.


Heading: Quality Control

Body: Records merged

Merge Record 1

Solution :

When merging records the Master is stored in the Master ID field in the subordinate record so you can create a workflow that runs on Contact entity when the record status changes.

Merge Record

Add a check condition step to check if Master ID contains data and the Contact state is inactive (this will prevent the creation of connection when a record is only being deactivated)


Leave a comment

Filed under MS CRM