Using single Mailbox Dynamics 365 User to Automatically Track All Outgoing and Incoming Emails from All Users (take 3)

This is the third post in my series about Automatic tracking of all Incoming and Outgoing emails in Dynamics 365 using Exchange Mailflow rules and Server Side Synchronisation.

In my previous post, I showed how we can track all incoming and outgoing emails for all users using 1 single Exchange Rule and for each user, we create 2 Outlook Rules. In this post, I have an even simpler solution with only 1 user and 2 exchange mail flow rules.

But firstly, it is important here to note that the main issue for automtiaclly automatically tracking outgoing emails is that any Outlook Rule for Sent emails is always “Client-only”. That is, the rule will only run if Outlook is open. I have not found a way to have an Outlook Rule that works server side to copy a sent email to a tracked Dynamics 365 folder. Hence, the use of Exchange Online Mail Flow and the direct use of the Exchange transportation layer.

But what if you don’t want to even create the outlook rules as per my two previous posts? The answer is simple: You can literally use 1 single Mail Box and Dynamics 365 user along with 2 Exchange Rules to automatically track all Outgoing and Incoming emails for any email inbox even if this user has not got Dynamics 365 App for outlook configured and even if this mailbox is not a Dynamics 365 user.

The approach is simple: Using 2 x Exchange Mail Flow rules you can Bcc every outgoing and every incoming email to all the mailboxes you want. All these emails are Bcc’ed to a Single Mailbox of a Dynamics 365 User who has App for Outlook configured. This way, all emails are tracked.

So to summarise:

  1. Setup and Configure Dynamics 365 App for outlook for one User: Let’s call it: “D365 Mail User”
  2. Create 1 x exchange rule to BCC all outgoing emails to this “Mail user”
  3. Create 1 x exchange rule to Bcc all incoming emails to the same “Mail user”
    and that’s it.

    Tried and tested – but please let me know if you got other ideas/thoughts.

Dynamics CRM Entity and Field Display Name, Field Schema Name and Field Logical name or Attribute name

In Dynamics CRM there is a difference between CRM Entities and Fields Display Name, Entity/Field Schema Name and Entity/Field Logical name (also known as Attribute name).

Display name is clear. It is the name shown to the CRM user and can have spaces, etc. Then you got these two:

  • SchemaName: Name that will be used to create the database column  for the field. This name can be mixed case. The casing that you use sets the name of the object generated for programming with strong types or when you use the REST endpoint. So it could be something like new_FieldSchemaName
  • LogicalName: This is the name, auto generated based on Schema name but the system sets it to all lowercase letters.

Every entity and field has a schema name (DB name – mixed case) and a logical name (all lower case).

Schema name retains the casing but logical name will always be lowercase.

When writing code to call/use fields, we always use schema names (DB names) not logical/attribute name.

As you can see from the following screenshot, you decide the display and schema name during creation while the attribute name will be generated by Dynamics CRM exactly as the schema name but all lower case.




Once your field is created, you can see in the following screenshot the Name (logical name), the schema name (DB name – mix case) and the Display name (the one the customer sees).




The same applies to entities.

This post may sound like it is targeting only those who are starting to work with Dynamics CRM for the first time, but in reality I have met a number of Dynamics CRM developers who didn’t know this information. Hence, I hope this is useful. Please comment with your views below.


Hide, Display, Resize and Rename left navigation links, CRM fields and attributes using Javascript for Microsoft Dyanmics CRM 4.

Scripts for Resizing, Hiding and renaming left navigation links, fields and attributes in Microsoft Dynamics CRM 4 using Javascript. This post is just a collection of some Javascript code for various common scripts that is frequently used in CRM form events, CRM entity events, etc. These script blocks can be used in OnLoad, OnSave events for CRM forms and OnChange events for CRM fields.

//------- Resize CRM form in the onload event
window.resizeTo(screen.availWidth * 0.85, screen.availHeight * 0.85);
//-------Rename left menu link / Left Navigation. Example: Contacts
var navItem = document.getElementById(’navContacts’);
navItem.innerHTML = navItem.innerHTML.replace(’>Contacts’,'>Students’);
//------Hide left menu link / Navigation. Example: Workflow
var navLeftItem = document.getElementById(’navAsyncOperations’); = ‘none’;
//-----Hide Left navigation menu item link of a CRM form based on
// a value in a picklist on the same form.
//Get contacts left navigation menu item element.
var navLeftItem = document.getElementById(’navContacts’);
//if picklist (customer type code) value is equal to 1 (1st item in picklist) then
//hide left menu item (contacts link is used as an example), otherwise, show it.
if(crmForm.all.customertypecode.DataValue == 1)
{ = ‘none’;
{ = ‘inline’;
 //-----Hide a CRM field on a form. example: the "name" field. = 'inline'; = 'inline';
//-----Hide a CRM field on a form (example: the "name" field)
//based on the selected value in a picklist
if(crmForm.all.customertypecode.DataValue == 1)
{ = 'inline'; = 'inline';
{ = 'none'; = 'none';
}  ////Add this code to the OnLoad event of the form and
////to the on change event of the picklist attribute (field) as well
//---------Function to hide CRM field in a form. 
//Function accept fieldname as a parameter and
//boolean parameter to remove (hide) entire row on form
HideField('name'); //replace "name" with your field/attribute name
function HideField( fieldName, removeEntireRow )
 // Always hide the elements, even if we will be hiding the whole row.
 // This allows us to show another field in this row later without this
 // one showing up.
 var elem = crmForm.all[fieldName + "_c"];
 if( elem != null ) = "none";
 elem = crmForm.all[fieldName + "_d"];
 if( elem != null ) = "none";     
 if (removeEntireRow)
  var elem = crmForm.all[fieldName + "_d"];
  if( elem != null ) = "none";

 This post was written quickly from memory and some code blocks here and there, so you might find some minor spelling mistakes. Please comment below if you find any issues with the script blocks or if you want me to extend this post to include additional script.

Methods to Bulk Delete Microsoft Dynamics CRM records and Using Scribe Insight to perform a Bulk Delete of all CRM records.

I’m sure many people needed to do a bulk delete operation on Microsoft Dynamics CRM 4.0. You may have uploaded thousands of records from an imported file or migrated them through Scribe or even used a .NET application to mass create records.

Unfortunately, and as far as I can see, there is no straight forward way to do bulk records deletion on Dynamics CRM 4.0 using the out of the box functionality and interface of Dynamics CRM 4.0.

To bulk delete records in Dynamics CRM 4.0, you have the following main options:

  • Get a third party tool or CRM add-on to bulk delete records. This option is a straight forward one but you might have to pay for purchasing or using the tool. It may also have security issues. I would not recommend it to my clients as most probably the tool is created by a small company or an individual which I don’t know. Hence, it will be rather difficult to put this tool on a live Production environment or client server. Let alone adding it to CRM Online or to a CRM hosted solution by a partner.
  • Use CRM SDK to write a .NET application (or a .NET console application) that will run and delete all records for a specified entity or entities. This is a more robust way of doing it, but it may take longer time and is probably not suitable for people who do not come from .NET development background.
  • Use Scribe Insight. This is what this post is about really.. Using Scribe Insight to bulk Delete Dynamics CRM records.

Please Note: This is a work around. It is not supported by Scribe and the advice in this post is provided as is with no warranty. I have tried it and it works perfectly but can not guarantee it will have the same acceptable results in any other environment.

Here is what you need to do:

  1. Create a new Scribe workbench DTS (or Job). Point to your usual source file (even a sample one) and point to CRM: either IFD Forms for hosted CRM or direct connection.
  2. Configure the targe: Create one delete step on the target.
  3. Make sure that the option to “Allow multiple record matches on updates/deletes” is ticked under the All steps tab.
  4. Under Step control tab, leave failure to go to next row but change all the success records (Success (0), Success (1) and Success (>1) ) to End Job. Select success radio button at the bottom and write a message to your log such as: “All records Deleted”.
  5. No Data links are important as you are only deleting.
  6. On the Lookup link, just make the lookup condition impossible. Such as: where Account Name = 123456789 or whatever.
  7. Run the DTS.

The Job will read the first source line. Will then try to find this record at the target (remember it is update/delete). Since we have setup the lookup link to look for something “impossible to find”, the result of the update will be Success (0).

Once this happens, Scribe will go and delete all records for your chosen entity (or CRM table). This will be a complete bulk delete of all CRM records using Scribe.

Remember, it’s a work around… that works.

A list of Important Questions you need to answer before starting any Integration solution or project.

I am currently working on an Integration solution for one of our clients. The solution is a general integration between two systems. The main thing for me was that I wanted to come up with a list of questions that I need an answer for so that I can start planning and designing the integration solution.

I thought about a list of general questions that most (if not all) consultants working on any integration solutions will need to have complete answers for before starting the design phase, let alone the development phase of the project.

In my opinion, the list of questions are as follows (not in real order – just a braindump!):

  • How many environments do you have? Development, Test and Live? (recommended) or is the project is still in development so you can use live environment for development? Where will be the test environment later on?
  • Is this a direct integration or in-direct integration? Is this an instant, event driven integration or a periodic scheduled integration between two systems? Are their queues for data to be migrated?
  • What backup and restore operations can you do? The ability to Backup and restore data is vital.
  • What integration application or tool are you going to use or is available? SCRIBE, SQL Server Integration Services, Web Services (Microsoft .NET Web Services), console applications, plugins? What SDK will you need? CRM SDK and CRM API for example?
  • The Environment structure: How many physical servers? Where are these servers located? Where is the integration tool or application installed?
  • How and When can I get access to the environment? Access to all servers is required including access to all databases and to all applications. For example: Access to Microsoft Dynamics CRM application (via webclient) is essential to confirm that data imported to a CRM has been migrated successfully.
  • What type and format of extracts and data imports? CSV (Comma separated Values), XML, i-Doc, sql flat files, batch files, etc…
  • Where will the extracts be imported? directly using the tool or via an FTP server? Is an SFTP server required?
  • Are their duplicates? If so where, and what classifies a duplicate?
  • Are there data entry standards for each application in the overall integrated system?
  • Are there fields that are required in each system part of this integration?
  • Are there fields that aren’t used?
  • Are there any fields with null values?
  • What relationship does the data has? are there fields which are dependant on others?
  • What are the primary and forign keys of all tables in each system that will be part of the integrated system? Any field that does not allow null, business required (and preferably business recommended) must have a data upon migration (Defauls can be used then).
  • Overall high level mapping between the different systems.
  • What is the value, length, and format of fields/columns in the source system? What is the corresponding value, length and format in the target system?
  • Are there any Pick Lists? A cross reference is required to map source and target values.
  • What Data validation is required and is acceptable by the client and the project stakeholders?
  • Differencing: What are the business rules for differencing? What data does not need to be updated and when? what data is needed to be updated based on the business requirements?
  • using Default values for all required fields and columns in the target system to avoid causing any errors.

This is the list I have thought of so far. I will keep on updating this list as and when I think of something important that needs to be considered.

Let me know if you have any comments or feedback on these questions and tell me whether or not are these questions helpful.

Thanks for reading.