Dynamics 365 – A First Look

Microsoft recently announced their next generation of Azure-hosted business services, titled Dynamics 365. General availability is scheduled for November 1st, 2016. Here is a first look at the features and functionality being provided as part of this new offering.


If you would like further information on how to prepare for the upcoming release of Dynamics 365, please contact us.

Using TraversedPath with Branching Business Flows

Using TraversedPath with Branching Business Process Flows


I recently ran into an issue with Opportunity records and branching Business Process Flows (BPFs) where all the stages were being displayed on the record, instead of what stages the record had gone through. The solution was interesting and I’d like to share the issue and resolution that I came up with.



The scenario I was working with involved using an external SQL Server Integration Services (SSIS) package that was creating new Opportunity records that were associated with a branched BPF in Dynamics 365. This external process would create the opportunity record and attempt to set the current stage to one of the stages in a particular branch. This was being done by setting the StageID field to the GUID of the stage that I wanted to make active.

The problem was that when viewing the created opportunity record, the BPF would display ALL the stages from both branches (I had 2 separate branches). Obviously, this was not desirable and was very confusing.



After analyzing the fields in Dynamics 365 for the opportunity record I had created, it turns out the reason why this issue arises is due to a field on the Opportunity entity called TraversedPath. This field is a comma-separated list of GUIDs that represents the BPF stages the opportunity record “traversed” through. I was not setting this field at all when creating the opportunity record, and therefore Dynamics 365 was displaying all the BPF stages from both branches (due to no entry in this field).

Once I modified my SSIS process to grab all the BPF stages I wanted the opportunity record to traverse through and set the TraversedPath field, the BPF stages (for the specific branch) were set and displayed properly.

I hope this article helps others in quickly determining the cause of the Business Process Flow issue I ran across.

Thanks for reading!



No-Code Configurations for Dynamics CRM – Part 2

This is the second article on how you can configure Dynamics CRM without writing code. In Part 1, I described the configuration options with System and Custom entities, as well as explaining how to use Business Rules. In this article, I will describe how you can configure Dynamics CRM using Workflows and Dialog, Business Process Flows, and Dashboards/Reports.


Workflows and Dialogs

Dynamics CRM provides an engine that can run business processes automatically or interactively. This engine allows administrators to create and manage these automated business processes in order to provide customized functionality to the CRM environment.

Workflows are business processes that run automatically, with little or no interaction with the user. These processes can be configured to run in the background or in real-time, and can be triggered automatically (based on a specified condition). They can also be started manually by a user.

For example, I can create a workflow by opening a solution in CRM and navigating to the Processes area. Once there, I can click on the New button to create a new process (see Figure 1).


Figure 1: Creating a new Workflow


New workflows start in a Draft state, which means they are not activated in the system. This allows you to create the workflow and add your logic to it, before you activate it. Figure 2 shows an example of a workflow in Draft state.


Figure 2: Workflow in Draft state

There are a number of areas when configuring a workflow that define what it does and how it runs. First off, you give it a name so you can recognize your workflow. Under the Available to Run section, you see there are a few checkboxes that allow you to define how the workflow will run in the CRM system. Selecting the Run this workflow in the background option will specify that the workflow runs in the background asynchronously. Unchecking this box specifies that the workflow will run as a real-time workflow, which means it runs synchronously (immediately).

The checkbox under the Workflow Job Retention section allows you to save (or delete automatically) the completed workflow jobs after it runs each time. Checking this box clears these records immediately, so that you can save disk space in your system. Be careful though – I have found that it’s nice to have these records around for a period of time, as you can determine if the workflow is running successfully.

The Entity and Category fields tell you what entity in CRM you are running the workflow against, and that the Category is a Workflow.

Under the Options for Automatic Processes section, you can define the workflow scope. This tells the workflow to run for a specific set of records, as listed below:

  • User – workflow only runs against the records owned by the current user
  • Business Unit – workflow only runs against the records owned by the business unit the current user belongs to
  • Parent: Child Business Units – workflow only runs against the records owned by business unit and the child business units the current user belongs to
  • Organization – workflow runs against any record in the organization

There are also checkboxes that specify what triggers the workflow. You can select when a record is created, record status changes, record is assigned, or when a record is deleted. You can also select when specific fields on the entity record change.

Once you’ve configured how the workflow should run, the main part of the workflow is defining what it does when it runs. This is done by creating one or more steps. Figure 2 shows the area in the workflow that allows you to create steps. Here is where you can add steps and their conditions, along with actions on what each step does. For example, Figure 2 shows a step that indicates that if the Opportunity:Presales Resource field = Yes and the Opportunity:Presales Resource field contains data, then the workflow should then check to see of the Opportunity:Probability <= 20. If it is, the action of sending an email is performed.

Once you’ve added all your steps and have saved the workflow, you can publish it to activate it into the CRM system. At this point, you would activate your workflow in a development system to test its functionality (before deploying it to a production system). You also have the ability to see when your workflow has executed (in your solution that contains the workflow), as shown in Figure 3. This view allows you to see what instances of your workflow has run, along with the status of their execution. You can drill into each record to see the details of the workflow execution, such as what steps performed successfully, or where it failed.


Figure 3: Workflow Process Sessions


Dialogs are very similar to workflows, as they are also business processes. However, these processes are designed to run and interact with the user. You create a dialog in the same way as a workflow process (except you select Dialog instead of Workflow category), and you will notice in Figure 4 that there are less configuration options than in workflows.


Figure 4: Configuring Dialogs

You still create steps in a dialog with actions, but you will notice there is a Prompt and Response selection, under a Page step. This is where you create and configure the dialog prompts that the users will see when the dialog runs. Figure 5 shows an example of a dialog prompt. You also have the ability to define what the prompt will say and how the user will respond.


Figure 5: Dialog Response Prompt Configuration


Business Process Flows

Business Process Flows are another type of process in Dynamics CRM, but they differ in how they provide functionality to users. I like to think of Business Process Flows (BPFs) as a guide in Dynamics CRM that helps users follow a set of steps to complete a process. BPFs have a visual component as well as back-end functionality that perform tasks or actions when the user is interacting with the BPF. They differ from workflows in that they have a UI component that users interact with while using the system. They also differ from dialogs in that they are persist on specific record types, meaning they are part of the displayed form. They are not triggered by an action and therefore do not “popup” a window to request that users add information at that point.

Administrators have the ability to create custom BPFs in Dynamics CRM, or you can use one of the following standard BPFs that come with Dynamics CRM. Some examples of standard BPFs are:

  • Lead to Opportunity Sales Process
  • Opportunity Sales Process
  • Phone to Case Process

The standard BPFs are good for general processes that you can have CRM users follow, but the real power of BPFs are displayed when you create a custom BPF that matches your business process. Figure 6 shows the Opportunity Sales Process that comes with Dynamics CRM.


Figure 6: Opportunity Sales Process BPF


Creating a Custom Business Process Flow

Creating a BPF doesn’t require specific coding skills, as CRM has provided an editor that allows administrators to create these processes without having to write code. You can navigate to the Settings area in CRM and click on Processes. This will navigate you to the My Processes view, which will show you a listing of processes owned by you:


Figure 7: My Processes View

From here, you can see which processes are in the system that are owned by you. This includes both workflows and BPFs. You can create a new BPF by clicking on the New button in the upper right. Once you click this, a designer is displayed that allows you to create a custom Business Process Flow (see Figure 8).

Business Process Flows consist of stages and steps. Stages are the different parts of the BPF that users can navigate back and forth from. Stages also contain one or more steps. Each step represents a piece of data that can be entered for the entity record the BPF is associated with. Figure 8 shows an example of a custom BPF with stages and steps:


Figure 8: Custom BPF with Stages and Steps

Note that when you create steps for a stage, you specify a field on the entity record the BPF is associated with. You can also designate whether the step is required. This means that the user cannot advance to the next stage until a value is entered for each of the required step fields in the stage (commonly known as stage-gating).

You will also notice from Figure 8 that there is a branched stage in the BPF. Branching BPFs gives the ability for a stage to only be displayed (and active) if a certain condition is met. In our example, the Procurement Approval stage is only displayed if the Budget Amount value (Step in Stage 1) is greater than $100,000. Figures 9 and 10 show what this branching looks like when the Budget Amount is above or below the $100,000 threshold.


Figure 9: Custom BPF with Branch Hidden


Figure 10: Custom BPF with Branch Displayed

Once you’ve created your custom BPF, you must activate it for it to be used in the system. All new BPFs you create start in a Draft state. You can have more than one BPF active in the system for an entity, and if you do there is an order to which BPF will be attached to the entity record (based on the first BPF the user has access to, via security roles). Figure 11 shows the Process Order Flow dialog for a custom BPF:


Figure 11: Process Flow Order Dialog


Dashboards and Reports

There are two different ways Dynamics CRM displays data in the system: Dashboards or Reports. This section will describe each and how they are used.



Dashboards display data from CRM as an overview of business data. Users can see data that they can perform actions against, and this data is usually displayed across the organization. If you wish to see CRM data at a glance, creating a dashboard will help you do that.

There are two types of dashboards in CRM: System Dashboards and User Dashboards. System Dashboards are created by a System Administrator or Customizer and these dashboards are visible to the entire organization. User Dashboards are created by CRM users and are only visible to the CRM user who created it. User Dashboards can be shared by the CRM user to other users, so that others can view the dashboard.

For either type of dashboard, CRM users have the ability to set the default dashboard they wish. System dashboards can be marked as the default dashboard for a specific area (Sales, Marketing, etc.) but if a user marks a different dashboard as their default (System or Custom) it will override the System dashboard that is marked as the default. Figure 12 shows an example of a default System dashboard.


Figure 12: Dashboards in Dynamics CRM

Dashboards can also be created to display either tabular data (like a view) or graphical data (like charts). Other types that can be included in a dashboard are Web Resources or IFrames. Users also have the ability to drill down into a dashboard chart to see the tabular data it represents. This gives the user the added functionality of being able to examine specific sets of data in a dashboard in more detail. Figure 13 shows a System dashboard with both tabular data and a chart:


Figure 13: Charts and Tabular Data in Dashboards in Dynamics CRM

One thing to remember when viewing dashboards: The data it displays must be accessible by the user viewing the dashboard. What this means is that if a user doesn’t have the security role to view a particular set of data, the dashboard itself will still be accessible but the data it displays will not be. Usually an error is displayed in the specific dashboard window that states the user doesn’t have the proper permissions to view the displayed data.



Dynamics CRM also has the ability for users to create and run reports. These differ from dashboards as they are a snapshot of data at the time the report is run. They are also typically used to print out (or export) data from the CRM system. Creating reports in CRM is a large topic, so I will focus on how users can run reports.

Users have the ability to run a report that is in the system. This is done by navigating to the Reports section (i.e. Sales -> Reports) which will display a view of the Available Reports the user can see:


Figure 14: Available Reports View in Dynamics CRM

Clicking on one of these reports displays a dialog that allows the user to modify the (pre-defined) criteria for the report, and then run the report (by clicking the Run Report button in the lower right):


Figure 15: Running a Report in Dynamics CRM

Once the Run Report button is clicked, CRM processes the request and will display the report results. At this point, the user has the ability to perform a number of actions on the report, such as modifying the filtering criteria (depends on the report), saving the report results to a file (Excel, PDF, etc.), or refreshing the data. Figure 16 shows an example of a displayed report:


Figure 16: Report Results in Dynamics CRM

The above description for running a report in CRM is for reports that run on all sets of data in the system. There is another type of report in Dynamics CRM that allows users to run a report against a single record in the system. These types of reports are useful for displaying a snapshot of detailed information about a specific record. This is done by opening a specific record in CRM (such as an Account record, for example). If you click on the command bar on the top of the page, you will see a section titled Run Report (see Figure 17). Clicking on this will expand a sub-menu, which will then display a listing of all the reports you can run against this record. Note that sometimes there may not be anything listed here if these types of reports have not been created in the system. Clicking on a selection here will display the report results. The user then has the ability to perform specific actions against the report results, as described earlier.


Figure 17: Selecting a Current Record Report in Dynamics CRM



As you can see, there are a multitude of different ways users and administrators of Dynamics CRM can configure the system without having to write a single line of code. These no-code configurations make Dynamics CRM a very powerful platform for tailoring the system to a business’s needs, and can take you very far into the realm of a custom CRM system for your organization.



No-Code Configurations for Dynamics CRM – Part 1

Microsoft has architected the Dynamics CRM platform to allow administrators to customize the environment to fit business needs, without requiring complex coding skills of a developer. This no-code configuration option is very powerful and allows the CRM environment to be built with a large portion of custom functionality before having to rely on custom scripting or coding practices.

This is the first article (of two) where I am going to detail out the different areas of no-code configurations, to give you an idea of what you can do with this type of customization in Dynamics CRM. Keep in mind that this list is not all-inclusive; I am only covering the larger areas of no-code configurations. I will be covering System and Custom Entities, along with Business Rules in this first part. Part 2 will cover Workflows and Dialogs, Business Process Flows, and Dashboards/Reports.


Configuring System Entities

Dynamics CRM comes with a set of system entities when installed. These entities make up the core of an out-of-the-box install. While you cannot delete a system entity (which is a good thing), you are able to configure them to extend their functionality. Here are some of the things you can do with system entities:

  • Create custom fields
  • Modify the Display Name of system fields
  • Change whether system fields are required/optional
  • Change the minimum/maximum range values on fields of certain data types (decimal number, for example)

There are some restrictions when configuring system entities, which are in place to protect and maintain system stability. Here are some of the things you cannot do:

  • Delete a system entity
  • Delete a non-custom field on a system entity
  • Change the data type of a field
  • Change the name of a field once it has been created

You can also create custom forms and views to extend how a system entity is displayed in the environment. Custom forms can be created to replace system forms to provide a custom look-and-feel. Custom fields can be added to system forms if a totally new form is not needed. System views can be configured to display additional fields or their filter criteria can be modified to provide custom data results. Custom views can also be created to be used in place of system views if other criteria or entity fields need to be displayed in the system. Please note that the filter criteria you can create are limited to what you can configure in the dialog window.


Figure 1: Example of System Form editor with Custom Fields

Another item to keep in mind is to make sure you publish any changes you make to the system, when you are ready to test them. Dynamics CRM allows you to make changes to the system without actually committing them. This allows you to load/add your changes and make edits before you actually apply them to the system. If you make changes and don’t publish them, they will not work as expected.


Figure 2: Example of Default Solution with Publish All Customizations button

Creating Custom Entities

If the system entities that Dynamics CRM provides is not enough for your requirements, you can also create your own custom entities. This is where CRM shines in terms of no-code customizations – you are able to create fully custom entities in the system without writing a single line of code! This allows you to configure your CRM system to fit almost any complex business requirements you may have.

There are a vast number of configuration possibilities here, but the most common I have seen is where custom entities are created to support the standard entities in the system. Sure, you can use custom entities completely, but why not leverage the functionality that Microsoft provides with Dynamics CRM, and then extend that functionality by creating custom entities that fit your need?

Please note that you are still not able to do certain things in the system, even with custom entities. For example, you are not able to change the data type on a field once it has been created. You are also not able to change the name of a field once it has been created.

Let’s go through an example. Suppose that we want to have our CRM system be able to display and keep track of automobiles owned by contacts. Since CRM doesn’t provide an entity out of the box to record automobiles (ignore the Products entity for this example J ), I can extend the functionality by creating a custom entity of my own to handle this.

The first thing I want to do is to design my custom entity, so it meets my business requirements. I would like to provide the following:

  • Allow a contact in CRM to own one or more automobiles
  • An automobile record in CRM has the following properties:
    • Make
    • Model
    • Year
    • Mileage
    • Owner
  • An automobile record in CRM can only be owned by one contact

Once I have these requirements, I can create the custom entity in CRM. This is done by creating an unmanaged solution (in the Settings->Solutions area) – I will call the solution AutomobileTest:


Figure 3: Creating a custom entity

Once you save your new custom entity, the dialog then allows you to create fields for the entity. Dynamics CRM creates some fields by default for you, such as the Name, CreatedBy, CreatedOn and Status.

As you create custom fields on your entity, note that the system prepends a publisher designator (“cncy_” in our example). A publisher is needed in order to create solutions in Dynamics CRM, and they are used to help manage customizations (managed or unmanaged).


Figure 4: Custom AutomobileTest solution with custom Automobile entity

Once the fields for our custom entity are defined, we can define the relationships between AutomobileTest and Contact entities. Since the requirements state one Contact can own multiple automobiles, and that each automobile record can only be owned by one Contact, that defines a N:1 relationship on our custom entity.


Figure 5: N:1 relationship between Automobile and Contact entities

Note that when creating this relationship, you must define the Primary and Related entities, along with a Display name. You can specify other attributes about the relationship, such as if it’s searchable, or the type of behavior (parental or referential).

There are 3 types of relationships available in Dynamics CRM:

  • 1:N (One-to-Many) – relates one entity record (the Primary) to one or more different entity records (the Related).
  • N:1 (Many-to-One) – the converse of 1:N relationships. This is really the same type of relationship as 1:N, just from the perspective of the related entity.
  • N:N (Many-to-Many) – relates many entity records to many different related entity records. Sometimes referred to as an Intersect entity.

Entity relationships are an important part of the Dynamics CRM schema, as they allow you to relate records to each other. This also allows the ability to define the schema to fit your business processes.


Business Rules

We now know how to configure standard or custom entities in Dynamics CRM that function in a standard and consistent manner. What do we do if we want to apply some custom logic on these entities? In the past the answer would have been to write some Javascript script code to implement this custom logic. Fortunately, Microsoft has introduced a declarative interface that allows you to create custom logic without writing Javascript. These are called Business Rules and are new (as of CRM 2013).

Business rules provide an easy way to evaluate business logic in Dynamics CRM, without the requirement of using custom code scripts. This can be performed on either the client or the server side. CRM provides a declarative interface that allows creation of these business rules, which can be applied against entity or entity fields. Please be aware that Business Rules in CRM do not replace custom scripting in CRM, as they are not able to perform all the things that custom scripting can perform. They can perform some of the more common things that scripting was providing in the past, as listed here:

  • Set field values
  • Clear field values
  • Set field requirement levels
  • Show or hide fields
  • Enable or disable fields
  • Validate data and show error messages

Also note that Business Rules will only work for Updated Entities (https://technet.microsoft.com/en-us/library/dn531143.aspx#BKMK_UpdatedEntities) or custom entities.

In order to create and configure a Business Rule in CRM, you need either the System Administrator or System Customizer security role. You will also need the Activate Business Rules privilege in order to activate a Business Rule. The rules you create are not applied until you activate them. Conversely, if you wish to edit a rule, you need to deactivate it first.

There are a few different ways you can access Business Rules in Dynamics CRM.

  1. Via Solution (Entity level)6
  2. Via Solution (Entity field level)7
  3. Form Editor (Entity level)8
  4. Form Editor (Entity field level)9


Business Rules have a scope – this determines the context of where the rule runs in Dynamics CRM. The different scope selections are:

  • Entity – runs on all forms and server
  • All Forms – runs on all forms
  • Specific Form – runs on that specific form

Note that you cannot select a scope of multiple specific forms. If you choose Specific Form, the rule will run on that one form only. This is also the default scope if you create a Business Rule via the form editor. Choosing All Forms means the rule will run on all the Main forms as well as the Quick Create forms, provided all the referenced fields are present on those forms.

Support for If/Else branches and AND/OR logic is supported for Business Rules. You can create logic in your business rules to check for certain conditions and perform specific actions if those conditions are met.


Figure 6: Business Rule with If/Else branch

There are a few limitations to be aware of. First off, nested If/Else statements are not supported. You can only have one level of If/Else statements. Grouping of expressions in a condition is not supported. Expressions can be combined using AND or OR, but not both. You also have a limit of 10 if/else conditions for a single Business Rule.

Conditions and actions are also supported for Business Rules. Conditions are the checks that you create to determine when specific actions are executed. Once a condition is met, the Actions you create will run as part of the rule. If a condition is not met, then the logic of the rule will skip over the action for when that condition is met.

There are a number of actions available:

  • Show error message – used to set error message text when a field is not valid
  • Set field value – used to set the value of the field. There are 3 types here:
    • Field – sets the value of one form field with the value of another field
    • Value – sets the value of one form field with an entered value
    • Formula – sets the value of one form field with a simple calculated field. Only valid for numeric or date data types
  • Set business required – used to change the requirement level for the field. Options are Business Required and Not Business Required
  • Set visibility – used to change whether the field is displayed/not displayed on the form. Options are Show Field and Hide Field
  • Lock or unlock field – used to change whether the field is enabled/disabled on the form. Options are Lock or Unlock

There are some general limitations when creating business rules:

  • Business Rules only run when the form loads or when field values change. They don’t fire on save, with the exception of when the scope is set to entity level
  • Business Rules only work with fields. If you wish to perform logic against tabs and sections you have to use custom scripts
  • If you set a field via a Business Rule, the system will not fire that field’s OnChange This is to protect against circular references
  • Business Rules that reference fields not present on a form will not run. No error will be displayed, so use caution if you’re removing fields from a form – always check that they are not being used on a Business Rule

Finally, you should be aware of the order in which logic is applied to Business Rules, in relation to system and custom scripts. First off, any system scripts are applied first. Next, any logic in custom form scripts is then applied. And finally, logic in Business Rules is now applied. If there are multiple Business Rules, they are executed in the order that they were activated.

In conclusion, you can see that using no-code configurations in Dynamics CRM has enormous power and flexibility in tailoring the environment to almost any business need. Part 2 of this series will discuss workflows and dialogs, business process flows, as well as dashboards and reports.






Customization Options for Dynamics CRM

This is the first post in a multi-part series on how to create customizations in Dynamics CRM. If you’ve ever used Dynamics CRM, you quickly learn that while it’s got a lot of features and functionality out-of-the-box, the system really needs to be customized to your specific environment to fully meet your business needs.

Once you realize this, your next questions are probably “How do I customize CRM?”, “What are my options to customize CRM?”, or “Do I have the skills to customize CRM?”. These are all great questions, and you should be asking them to ensure your efforts are set on a path to success. I will list out the different ways you can customize your Dynamics CRM environment at a higher level, so you can get a general idea of what area fits your level of customization (and skill).

There are three main areas of customization for Dynamics CRM, described below:

No-Code Configurations

The first place to start when you are considering customizing your Dynamics CRM environment. Dynamics CRM provides a very robust platform to create customizations on the out-of-the-box entities, forms and fields, without having to write complex code solutions.

You can get very far with these types of no-code configurations. I’ve seen full CRM implementations that use no-code configurations as their only customizations, and they don’t have one line of custom code at all! Here are some of the things you can do with no-code configurations:

  • Extend standard entities to add custom fields
  • Create your own custom forms to extend standard entities
  • Create your own custom entities
  • Extend standard views to display additional information
  • Create your own custom views
  • Create your own custom business process flows
  • Create workflows that provide custom logic
  • Create business rules that enforce data integrity

Part 1 can be found here.

Javascript Customizations

If you find that no-code configurations do not satisfy the customizations you need, the next area you should consider is creating custom Javascript files. Dynamics CRM uses Javascript files to perform a multitude of things related to how the forms look/operate, as well as other UI considerations.

If you need to customize Dynamics CRM to perform things when a form loads, or when a field entry value changes, then Javascript files are a good fit. The drawback here is that you need to have the skills to write Javascript code in order to properly implement this type of customization, so it is not as easy as the no-code configuration option.

Please note that Business Rules were introduced in Dynamics CRM 2013 as Microsoft’s way to “lower the bar” for creating Javascript customizations. Business Rules are a no-code way to perform the same (or similar) functionality that Javascript customizations currently provide. CRM provides a designer “surface” to create these rules, so that CRM administrators can create these rules without having to know Javascript.

Some of the things you can do with Javascript files or Business Rules are listed here:

  • Set the value of a field on a form, based on some criteria
  • Make a field on a form required when a value in another field is changed
  • Show an error message when an invalid entry is entered for a field
  • Show or hide a field depending on criteria
  • Enable or disable a field depending on criteria

Code Customizations

If no-code configurations or Javascript customizations do not fit the custom functionality you need to implement, the final option you have is code customizations. This requires the highest level of skills for customizing Dynamics CRM, as the person implementing the customizations (usually a developer) needs to know how to write code.

Code customizations usually are created as plugins, custom workflow activities, or custom web applications that can be embedded in CRM forms. Many companies offer 3rd party application solutions that you can add to your Dynamics CRM environment to extend the out-of-the-box functionality. These 3rd party solutions are custom-coded by their own developers, but if you purchase their application you don’t have to worry about writing code for the functionality (as they have already done that) – you just install the application and you’re good to go!

Custom plugins are designed to execute when an event or action occurs in Dynamics CRM, such as an update or delete of a certain type of record (for example, when an Account record is deleted). The plugin uses a code software development kit (SDK) provided by Microsoft to access the CRM environment to perform whatever custom logic needed.

Custom workflow activities are similar to plugins, but they are not executed when an event or action occurs in the CRM system. They are designed to be added to workflows in CRM, so that when a CRM administrator is creating a no-code workflow they can select a custom workflow activity to perform specific functionality. This extends CRM workflows to perform almost anything you can imagine in the system!

Custom web applications are server-hosted web applications written with custom code (ASP.NET for example) that are hosted on a web server that your Dynamics CRM environment can access. These custom web application pages can be embedded into a standard CRM form, to customize that form in CRM. There are many possibilities here on what can be created, so I will address that in a later post.


In conclusion, I hope you can see that the customization options for Dynamics CRM are numerous and these choices help make the Dynamics CRM an extremely customizable platform to fit any business need.

Please stay tuned for further details on customizing Dynamics CRM, as I will be updating this article with links to future blog articles. Happy customizing!


Creating an Audit Report for User Logins in Dynamics CRM

If you’ve ever tried to create an audit report for Dynamics CRM, you may have noticed that you can’t create one with the Report Wizard. The Audit Summary Report in the Settings area gives you some information, provided you enable auditing for the correct entities. However, if you need detailed information on your report, or you wish to share this report to others in CRM, you quickly realize that your options are limited.

Fortunately, there is another option that you can take to overcome these challenges. This option involves writing a custom SQL Server Reporting Services (SSRS) report that can be uploaded into CRM and shared with others to provide auditing information. I will describe how I created a report to provide detailed login information for CRM users. This article assumes the reader understands how to create a custom SSRS report for Dynamics CRM.

The first challenge I encountered was deciding how to write the query for my custom SSRS report. I have 2 choices: a SQL query or a FetchXML query. Writing a SQL query will work if the report is grabbing data from an on-premises version of CRM, but what would I do if I wanted to write this report for CRM Online? Since I can’t write a SQL query for CRM Online, I am forced to use FetchXML for the report.

My first thought was “Can I access the audit tables via FetchXML like I can with SQL?”. After a bit of searching, I found a GitHub project that had a couple of SSRS reports that accessed the audit tables via FetchXML (credit to BrettRojas: https://github.com/BrettRojas/CRM2011UserAuditReport). Once I examined the query, I realized that with a bit of SSRS report manipulation I could use this to provide a detailed login report in CRM Online.


FetchXML Query

The query for this report is listed here:

<fetch distinct="false" no-lock="false" mapping="logical">

<entity name="audit">

   <attribute name="createdon" />

   <attribute name="action" />

   <attribute name="userid" />

   <attribute name="objectid" />

   <attribute name="objecttypecode" />

   <order attribute="createdon" descending="true" />

<filter type='and'>

   <condition attribute='action' operator='eq' value='64'/>


<link-entity name='systemuser' from='systemuserid' to='objectid' link-type='outer' alias='SystemUser'>

   <attribute name="fullname" />

   <attribute name="windowsliveid" />

   <attribute name="businessunitid" />

   <attribute name="isdisabled" />





There are a few things to note about this query:

  • Enabling Auditing – Auditing in CRM must be enabled for this report to function properly. Since we are creating a login report, we need to enable auditing for the SystemUser entity in CRM.CRMAuditReport2
  • Query Entity – The entity used in the query is titled Audit, which is an internal entity in Dynamics CRM. This means it is not displayed in the Advanced Find dialog, nor the query generator for the Report Wizard. You still have access to this entity, but you need to have System Administrator privileges to do so.
  • Action Attribute – This attribute in the Audit entity describes the type of record being recorded. We are only interested in entries with the integer value of 64, which corresponds to a successful access via a web page. Since only CRM users would access the system via a web page, we can safely assume that these are real CRM users logging in to the system. As a side note, the original FetchXML query included entries with the value of 65, but this corresponds to a successful access to CRM via a webservices call (such as a plugin) and we do not need these records for our report.
  • Linked Entity – The query also performs an outer link to the SystemUser entity, in order to get the details we need for our report. Since the Audit entity only has the GUID for the main entity record being tracked (SystemUser in our case), we need to perform this link so we can see information such as the name of the user, their business unit, Windows Live ID, and their status (active/disabled).
  • Ordering of Results – The query performs an ordering of the results, and uses the CreatedOn field from the Audit entity. Since we are tracking SystemUser records, this field corresponds to a successful login by a CRM user, so ordering the query results in descending order assures us that the first record return for each CRM user (if we group by CRM users) will be the latest login.


Creating and Publishing the Report

You can now use the above query to create your SSRS report (and publish to CRM) using the normal techniques and processes to do so. Here is an example of the layout of the report that I created – you can display information about specific users, such as Last Login or Number of Logins over the last 30 days. Please note that the data displayed on this report will start when you enable auditing (as mentioned above).


I hope this is helpful – Happy reporting!



Using SSIS to Import Data into Dynamics CRM

I am constantly being asked to import data into Dynamics CRM from various sources, and over time I have discovered that, even though the sources of data that I am importing vary, the process of performing the import is similar. Which tool I choose to use depends heavily on the source of the data, along with the format it comes in, and whether or not any manipulation needs to be performed prior to the actual import.

Even though 3rd party tools like Scribe <http://www.scribesoft.com/ > are great for doing these data imports, sometimes it isn’t the best fit for a client. There are times when SQL Server Integration Services (SSIS) are a better choice, and I will describe the steps to create an SSIS package to import data into Dynamics CRM. Using the out-of-the-box data import feature in Dynamics CRM is another option, but I would like to focus on the SSIS package in this article.

Data Source Definition

Before we can create an SSIS package to perform the import, we need to define a data source. This may already be defined for your scenario, but for this article I created a SQL database that represents account information.


Figure 1: Data Source for Accounts


Creating the SSIS Package

Once the data source has been defined, we can now use SQL Server Data Tools (SSDT) to create an Integration Services project. This project will define our SSIS package, which has the steps we need to perform to do the data import.


Figure 2: Integration Services Project

When a package is created in the project, it starts you out on the Control Flow tab (Figure 2). I can add either a Data Flow Task or an Execute SQL Task. I’m using a Data Flow Task in the package, as this will allow me to define the data source connection, the destination to import the data to, as well as any steps I want to perform.

The Data Flow tab displays a designer for the Data Flow Task(s) you define in the package (you can have more than one). This designer surface allows you to build out your source and destination connections, along with any manipulation steps you need to perform before the data is imported.


Figure 3: Data Flow Task in SSIS Project

For my package, I don’t need to manipulate the data before I import it into Dynamics CRM, so the only items I need to define in the Data Flow task are the source and destination. For the source, I’m using an OLE DB Source object, and this has been configured to go directly against the Accounts table in the database (Figure 4). I also mapped all the columns, as I want to import all this information, as seen in Figure 5.


Figure 4: Source Connection Definition


Figure 5: Column Mapping


Adding the Script Component

For the destination, we need to setup a Script Component as we will be using c# code (using the Dynamics CRM SDK assemblies) to import the data into our Dynamics CRM organization, as shown in Figure 6.


Figure 6: Script Component in SSIS

I then mapped the columns coming from the source data, so that my code can access this to perform the import. Figure 7 shows how I mapped the columns – you can select only the data columns you want to import, and also have the ability to rename the column names (if you want friendly names, for example).


Figure 7: Script Component Column Mapping


Adding Code to Perform the Data Import

Now we are ready to add the code that does the actual import of data into Dynamics CRM. Clicking on the Edit Script… button (Figure 6) will open Visual Studio with a special project type (VstaProjects) that contains a “shell” project which you can add code to.

There are 2 methods that we need to add code to, in order to connect to a Dynamics CRM instance and perform the data import. The first method is PreExecute() and we override this method so that we can first connect to a Dynamics CRM instance using our credentials. Figure 8 shows the format for connecting to a Dynamics CRM Online organization, along with the code (commented out) on how to connect to an on-premises Dynamics CRM organization. Please note that the UserName you use when connecting to CRM Online must be a valid CRM user in the organization you are connecting to.


Figure 8: Visual Studio Project from Script Component

The other method we need to add code to is Input0_ProcessInputRow(), and this method is executed for each row of data coming from the source. We want to create a new Account record in Dynamics CRM for each row, so Figure 9 shows the code that does this. Note that this code can get a lot more sophisticated, based on what you need to do during the import.


Figure 9: Code to Import Data


Final Thoughts

I came across a couple of issues when developing the Script Component for my SSIS package and would like to mention them here.

  • In order to use the Dynamics CRM SDK, I needed to add references to the Microsoft.xrm.sdk.dll and Microsoft.crm.sdk.proxy.dll files. I found that I received an “Assembly not found” error when running the SSIS package, and this was due to the fact that I needed to copy these DLL files to a specific directory under the local SQL Server installation directory location. Here is a link that describes the problem:


  • I also ran across problems when attempting to use early binding in the Script Component Visual Studio project. When I added the cs file generated from the CrmSvcUtil.exe program to the project, I would get the “Assembly not loaded” error when running the project. Adding the DLL files (as described above) didn’t resolve the problem, so I resorted to use late binding.

So, if you are familiar with SSIS and need greater control over your data import process, the process explained here may be an option for you. I hope this article is helpful in providing another option for importing data into Dynamics CRM.



PowerView Reports in Dynamics CRM 2013

Dynamics CRM does a really good job of hosting and tracking a company’s critical business data, and the PowerBI technology stack does a great job of modeling and displaying business data to end users. While Dynamics CRM does a decent job of providing dashboards to surface this business data, I thought “wouldn’t it be great if CRM users had native access to PowerView reports while using Dynamics CRM”? Well, it turns out that with a little configuration you can provide these types of reports right in Dynamics CRM! Let me explain the process I took to do this:

First off, you need to use the PowerBI stack to extract data from a source (Dynamics CRM, for example), manipulate it in a PowerPivot (or SQL Server Analysis Services) data model and create a PowerView report. I did this for the Top 100 Global Companies and created a PowerMap report hosted in a SharePoint Online instance, as shown in Figure 1. Please refer to this post <<link to my other blog on surfacing LOB data into PowerView reports>> for further details on creating PowerView reports from LOB data sources.


Figure 1: PowerMap Report in SharePoint Online

Once this is setup, you can then create a system dashboard in Dynamics CRM to host the PowerView report (Figure 2). Please note that this won’t work with Personal Dashboards, due to the fact that you need to configure the IFrame without restricting cross-domain scripting.


Figure 2: Creating a System Dashboard in Dynamics CRM

You will use an IFrame on the dashboard to reference the PowerView report in SharePoint, so you can open the report in a separate window and copy the URL into the IFrame properties, under the URL field. You need to make sure the Restrict Cross-Domain Scripting checkbox is cleared, and should also verify that the URL you copy has the &action=embedview in the querystring (so it renders properly within the page).


Figure 3: Creating an IFrame in Dynamics CRM

Once you configure this and publish to Dynamics CRM, you will then have a fully-functioning dashboard that displays PowerView reports! One final note to mention: authentication is an issue here, as the CRM user should also have a login to the SharePoint site that the PowerView report is hosted in, otherwise you will get a nasty error when displaying the dashboard (Figure 5).


Figure 4: PowerMap Report in Dynamics CRM Dashboard


Figure 5: Authentication Error with PowerView Reports in Dynamics CRM

I hope this blog helps others to quickly get these awesome reports working in Dynamics CRM. Enjoy!


Microsoft Dynamics CRM Use Rights (IUR) Program Changes

If you work for a Microsoft Partner and use Dynamics CRM or CRM Online, the current Internal Use Rights (IUR) program is changing. I recently spent some time planning for these changes in my organization, and I’d like to details these experiences so other partners can save some time and headache moving to the new IUR program.


Microsoft announced the changes to the IUR program a few months ago, so I won’t cover the details of those changes. More information can be found here (you will need login credentials to PartnerSource to access the page):


The preparation for the new IUR program is to have a migration plan in place prior to signing up for this new program, so you can be assured your users will be migrated successfully to the new plan. For myself, all this meant was to verify our tenant was upgraded from Commerce Transaction Platform (CTP) to Office 365 (which it was previously), and then check that the new program had enough CRM licenses to handle the number of users my organization had in our current system. Since we are a Dynamics CRM Gold partner, we receive 80 CRM Online licenses (down from the 250 in the retiring IUR program). Fortunately, the number of users we have in our current CRM system is below 80, so all I had to do was sign up for the new program and migrate over the users, and I should be good to go.

The instructions I received from Microsoft were very detailed and were easy to follow, so I proceeded to step through them. The starting point was to login to the Partner Digital Download site and navigate to the Microsoft Online Services tab:


This area displays the product keys that can be used to redeem for the IUR benefits that my organization is eligible for:


Once I clicked the link to redeem, I was taken to our Office 365 administrative panel where I logged in and followed the steps to redeem using the eligible product key token. The webpage then gives you an opportunity to purchase additional licenses but I didn’t need to do that.

At this point I was able to see the new IUR subscription listed in our Office 365 admin panel, alongside the IUR program that is being retired. The next step I took was to migrate the CRM licenses for the users to the new IUR program. I did that and verified in CRM that users with licenses in this new IUR program were listed as enabled users, while users that didn’t have a license were listed as disabled users in CRM.

There was only one issue I experienced when performing these steps and it really threw me for a loop, as it affected our CRM users in our production environment. We purchase additional storage space for our CRM Online environment, as the size of our database is larger than the 5GB provided when you provision a CRM environment.

When I completed the steps of signing up for the new IUR program and migrating the CRM user licenses, I began receiving messages that our production CRM environment has run out of space and that users cannot add records. This puzzled me and when I went to the Resources In Use screen (in Settings) I saw that our instance was only allocated the initial 5GB of space:


I went back into Office 365 to verify that we were still purchasing the additional space for CRM and when I verified that, I felt it was time to bring in Microsoft Support to help.

In Microsoft’s defense, I usually have a good experience when reaching out to their support teams for help, but this issue was such a strange one that I think Microsoft was unclear how to help me resolve it. I won’t bore you with the details of each support team I talked to (I spoke with more than a few) but the bottom line is that the support team I spoke with that was able to help me was the Billing Support team. Let me repeat this for emphasis: Microsoft Billing was able to resolve a production-level technical problem I had.

As it turns out, if you previously purchased additional space for your CRM system (like we did), signing up for the new CRM IUR program somehow doesn’t automatically move your additional space purchase to the program, and thereby the CRM system doesn’t recognize that you are already paying for that additional storage space. MS Billing was able to provide me with a one-time signup web page that allowed me to request additional storage space that the new CRM IUR program does recognize, so once I did that our CRM environment recognized the additional space I purchased.


I hope this post helps if other partners experience issues migrating to the new IUR program, and also to show that Microsoft Support has a lot of great people that are dedicated to help partners solve their problems.






Integrating Yammer into Dynamics CRM 2013

Social selling is becoming more important these days, as companies are looking to find creative ways to generate more opportunities. Microsoft provides support for this in the Dynamics CRM space by providing integration with Yammer and CRM 2013. I’m going to show you how easy it is to setup Yammer to work with Dynamics CRM 2013, so your sales force can begin using its social features.



  1. Yammer Enterprise. Integrating Yammer with CRM 2013 requires the enterprise version of Yammer
  2. The user performing the integration with Yammer requires system administrator privileges in CRM 2013
  3. The user performing the integration with Yammer requires system administrator privileges for your organization’s Yammer account
  4. Install the most recent product updates for Dynamics CRM 2013



  1. Login to Dynamics CRM 2013 and navigate to the Settings area. This is done by clicking on Microsoft Dynamics CRM –> Settings
  2. Navigate to the Administration section by clicking on Settings –> Administration
  3. Click on the link titled “Yammer Configuration” to begin the wizard steps to enable the integration. Please note that you will not see this link if you do not have System Administrator privileges in Dynamics CRM.


  1. A Yammer Disclaimer page will display, asking you to agree to the disclaimer. Click on Continue to proceed.


  1. A configuration page will appear, with steps listed on how to connect your Yammer environment to Dynamics CRM 2013. Notice that only the first step (“Authorize Microsoft Dynamics CRM Online to connect to Yammer”) will be enabled at this point. Click on this link to perform the authorization step.


  1. A dialog will display requesting you enter your Yammer credentials for the authorization. Enter these credentials and click the “Log In” button.


  1. Another dialog will be displayed that asks you to confirm the connection between Yammer and Dynamics CRM 2013. Click on the “Allow” button to allow this connection.
  2. At this point the integration is performed and complete, but the process takes you back to the Yammer configuration page, and you will notice that steps 2 and 3 are now enabled. These are optional steps that you can configure for specific items/behavior with the Yammer integration.


  1. (Optional) Select a Yammer Group ID to control conversation access. This optional step allows you to configure whether all the conversations initiated from Dynamics CRM should be placed in a specific group in Yammer. If you don’t specify a group, the All Company Group is used for this.
  2. (Optional) Set the level of security for Yammer activity stream messages. This optional step allows you to configure whether the conversations in Dynamics CRM are visible to everyone (Public). Selecting Private for this setting will require users in Dynamics CRM to follow the appropriate record in order to see the Yammer conversations.


Configuring Entities

Once Yammer has been connected to Dynamics CRM 2013, you need to specify which entities in CRM you wish to enable for use with Yammer. This can be done by navigating to the Post Configuration section in Settings (click Settings –>Post Configurations).

In order to activate an entity for use with Yammer, select the desired entity and click the Activate selection in the top navigation bar. Deactivating an entity for use with Yammer is done by clicking the Deactivate selection in the top navigation bar. Please make sure you Publish All Customizations to verify that the changes you made take effect in Dynamics CRM.


Reactivating an inactivated entity for Post Configurations will restore any conversations in Yammer (they are not deleted when you inactivate an entity as the messages are stored in Yammer, not Dynamics CRM).


Issues to be Aware Of

There is only one issue I encountered when configuring the Yammer integration with Dynamics CRM 2013. You need to make sure you have your URLs for your Dynamics CRM organization as well as the URL for Yammer in your Trusted Sites zone in Internet Explorer options. Since my Dynamics CRM environment is online, the URL I used was https://*.crm.dynamics.com, and https://www.yammer.com. If you forget to do this, you may run into an issue when you complete Step 6 (I encountered a blank screen that sat there forever).



That’s it! You now have the social power of Yammer integrated into Dynamics CRM 2013, and can begin to leverage the benefits of social tools for your Dynamics CRM environment!