Workflow processes in Dynamics CRM 2013

Workflows automate business processes without a user interface. People usually use workflow processes to initiate automation that doesn’t require any user interaction.
Though workflows are not new in Dynamics CRM 2013, however Microsoft introduced new feature in Dynamics CRM 2013 that allows users to create real-time/synchronous workflows.
Each workflow process is associated with a single entity. When configuring workflows you have four major areas to consider:

  • When to start them?
  • Should they run as a real-time workflow or a background workflow?
  • What actions should they perform?
  • Under what conditions should actions be performed?

1. Where do you customize workflow processes?
You can see the workflows in your organization by viewing the ‘Processes’ node in the ‘Default Solution’ and filtering on processes that have the ‘Category Workflow’.

2. Workflow properties
In the solution explorer, select ‘Processes’ and click ‘New’.
When you create a workflow the ‘Create Process’ dialog requires that you set three properties that all processes have:
– Process name: The name of the workflow process does not need to be unique, but if you expect you will have a lot of workflows, you may want to use a naming convention to clearly differentiate your processes. You may want to apply standard prefixes to the name of the workflow. The prefix may describe the function of the workflow or the department within the company. This will help you group similar items in the list of workflows.
– Category: This property establishes that this is a workflow process.
– Entity: Each workflow process must be set to a single entity. You can’t change the entity after the workflow process is created.
– Run this workflow in the background (recommended): This option appears when you select workflow as the category. This setting determines whether the workflow is a real-time or background workflow. Real-time workflows run immediately (synchronously) and background workflows run asynchronously. The configuration options available depend on your choice for this setting. Background workflows allow for wait conditions that are not available for real-time workflows. As long as you don’t use those wait conditions, at a later time you can convert background workflows to real-time workflows and real-time workflows to background workflows.
You also have the ‘Type’ option to specify whether to build a new workflow from scratch or choose to start from an existing template. When you choose ‘New process from an existing template (select from list)’ you can choose from the available Workflows processes that were previously saved as a process template.
After you create the Workflow or if you edit an existing one, you will have the following additional properties:
– Activate As: You can choose ‘Process template’ to create an advanced starting point for other templates. If you choose this option, after you activate the workflow it will not be applied but instead it will be available to select in the ‘Create Process’ dialog if you select ‘Type: New process from an existing template (select from list)’
Process templates are convenient when you have a number of similar workflow processes and want to define them without duplicating the same logic.
Note: Editing a process template does not change the behaviors of any other workflow processes previously created using it as a template. A new workflow created using a template is a copy of the content in the template.
– Available to Run: This section contain options that describe how the workflow is available to be run.
– Run this Workflow in the background (recommended):This check box reflects the option you selected when you created the workflow. This option is disabled, but you can change it from the ‘Actions’ menu by choosing either ‘Convert to a real-time workflow’ or ‘Convert to a background workflow’.
– As an on-demand process: Choose this option if you want to allow users to run this workflow from the ‘Run Workflow’ command.
– As a child process: Choose this option if you want to allow the workflow to be available to be started from another workflow.
– Scope: For user-owned entities, options are Organization, Parent: Child Business Units, Business Unit, or User. For Organization-owned entities the only option is Organization.
If scope is Organization, then the workflow logic can be applied to any record in the organization. Otherwise, the workflow can only be applied to a subset of records that fall within the scope.
Note: The default scope value is User. Make sure you verify that the scope value is appropriate before you activate the workflow.
– Start When: Use the options in this section to specify when a workflow should start automatically. You can configure a real-time workflow to be run before certain events. This is a very powerful capability because the workflow can stop the action before it occurs.

  • Record is created
  • Record status changes
  • Record is assigned
  • Record fields change
  • Record is deleted

Note: Keep in mind that the actions and conditions you define for the workflow are not aware of when the workflow is run. For example, if you define a workflow to update the record, this action can’t be performed by a real-time workflow before the record is created. A record that doesn’t exist cannot be updated. Similarly, a background workflow can’t update a record that has been deleted, even though you could define this action for the workflow. If you configure a workflow to perform an action that can’t be performed, it will fail and the entire workflow will fail.
– Execute As: This option is only available if you unselected the ‘Run this workflow in the background (recommended)’ option when you created the workflow or if you later converted a background workflow to be a real-time workflow.

3. Security context of workflow processes
When a background workflow is configured as an on-demand process and is started by a user using the Run Workflow’ command, 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.
When a background workflow starts based on an event the workflow operates in the context of the person who owns it, usually the person who created the workflow.
For real-time workflows you have the Execute As’ option and you can choose whether the workflow should apply the security context of the owner of the workflow or the user who made changes to the record. If your workflow includes actions which all users would not be able to perform based on security constraints, you should choose to have the workflow run as the owner of the workflow.

4. Activate a workflow
Workflows can only be edited while they are deactivated. Before a workflow can be used manually or be applied due to events it has to be activated. Before a workflow can be activated it must contain at least one step.
A workflow can only be activated or deactivated by the workflow owner or by someone with the Act on Behalf of Another User’ privilege such as the system administrator.  The reason for this is that a malicious user could modify someone’s workflow without them being aware of the change. You can reassign a workflow you own by changing the owner. This field is on the Administration’ tab. If you are not the system administrator and you need to edit a workflow that has to owned by another user, you need them to deactivate it and assign it to you. After you finish editing the workflow, you can to assign it back to them and they will need to activate it.
Real-time workflows require that the user have the ‘Activate Real-time Processes’ privilege. Because real-time workflows have a greater risk of affecting system performance, only people who can evaluate the potential risk should be given this privilege.
Workflows are saved when they are activated, so it is not necessary to save them before activating them.

5. Configure workflow steps
When configuring workflows you have four major areas to consider:

  • When to start them?
  • Should they run as a real-time workflow or a background workflow?
  • What actions should they perform?
  • Under what conditions actions should be performed?

 5.1 Workflow stages and steps: When you design workflows you have the option to contain the logic you want to perform in stages and steps.
Stages: Stages make the workflow logic easier to read, and explain the workflow logic. However, stages do not affect the logic or behavior of workflows. If a process has stages, all the steps within the process must be contained with a stage.
Steps: Steps are a unit of business logic within a workflow. Steps can include conditions, actions, other steps, or a combination of these elements.
5.2 Actions that workflow processes can perform: Workflow processes can perform the actions listed in the following table.

Action Description
Create Record Creates a new record for an entity you choose and assigns values you choose to attributes.
Update Record You can update the record that the workflow is running on, any of the records linked to that record in an N:1 relationships, or any records created by earlier steps.
Assign Record You can assign the record that the workflow is running on, any of the records linked to that record with an N:1 relationship, or any records created by earlier steps.
Send Email Sends an email. You can choose to create a new email message or use an email template configured for the entity of the record that the workflow is running on or any entities that have an N:1 relationship with the entity, or the entity for any records created by earlier steps.
Start Child Workflow Starts a workflow process that has been configured as a child workflow.
Change Status Changes the status of the record that the process is running on, any of the records linked to that record with an N:1 relationship, or any records created by earlier steps.
Stop Workflow Stops the current workflow. You can set a status of either Succeeded or Cancelled and specify a status message.When real-time workflows are configured for an event, stopping a workflow with a status of cancelled will prevent the event action from completing.
Custom Step Developers can create custom workflow steps that define actions. There are no custom steps available in Microsoft Dynamics CRM by default.

5.3 Setting record values: When you create a record you can set values for the record. When you update a record you can set, append, increment, decrement, multiply, or clear values.
When you click ‘Set Properties’, a dialog opens showing you the default form for the entity.
At the bottom of the dialog you can see a list of additional fields not present in the form.
For any field, you can set a static value and that will be set by the workflow.
On the right side of the dialog the ‘Form Assistant’ gives you the ability to set or append dynamic values from the context of the current record. This includes values from related records that can be accessed from the N:1 (many-to-one) relationships for the entity.
The options available in the ‘Form Assistant’ depend on the field you have selected in the form. When you set a dynamic value, you will see a yellow placeholder known as a ‘slug’ that shows where the dynamic data will be included. If you want to remove the value, just select the slug and delete it. For text fields, you can use a combination of static and dynamic data.
With dynamic values you don’t know for certain that a field or related entity has the value you want to set. You can actually set a number of fields to try and set the value and sort them in order using the green arrows. If the first field doesn’t have data, the second field will be tried and so on. If none of the fields have data, you can specify a default value to be used.
5.4 Setting conditions for workflow actions: The actions that you will apply often depend on conditions. Workflow processes provide several ways to set conditions and create branching logic to get the results you want. You can check values of the record that the workflow process is running against, any of the records linked to that record with an N:1 relationship, or values within the process itself

Condition Type Description
Check Condition A logical “if-<condition> then” statement.
You can check values for the record that the workflow is running on, any of the records linked to that record in an N:1 relationships, or any records created by earlier steps. Based on these values you can define additional steps when the condition is true.
Conditional Branch A logical “else-if-then” statement, the editor uses the text “Otherwise, if <condition> then:”
Select a check condition you have previously defined and you can add a conditional branch to define additional steps when the check condition returns false.
Default Action A logical “else” statement. the editor uses the text “Otherwise:”
Select a check condition, conditional branch, wait condition, or parallel wait branch that you have previously defined and you can use a default action to define steps for all cases that do not match the criteria defined in condition or branch elements.
Wait Condition Enables a background workflow to pause itself until the criteria defined by the condition have been met. The workflow starts again automatically when the criteria in the wait condition have been met.
Real-time workflows cannot use wait conditions.
Parallel Wait Branch Defines an alternative wait condition for a background workflow with a corresponding set of additional steps that are performed only when the initial criterion is met. You can use parallel wait branches to create time limits in your workflow logic. They help prevent the workflow from waiting indefinitely until the criteria defined in a wait condition have been met.
Custom Step Developers can create custom workflow steps that define conditions. There are no custom steps available in Microsoft Dynamics CRM by default.

5.5 Using real-time workflows: With Microsoft Dynamics CRM 2013 you can configure real-time workflows but you should use them with care. Background workflows are generally recommended because they allow the system to apply them as resources on the server are available. This helps smooth out the work the server has to do and help maintain the best performance for everyone using the system. The drawback is that actions defined by background workflows are not immediate. You can’t predict when they will be applied, but generally it will take a few minutes. For most automation of business processes this is fine because people using the system don’t need to be consciously aware that the process is running.

Use real-time workflows when a business process requires someone to immediately see the results of the process or if you want the ability to cancel an operation. For example, you may want to set certain default values for a record the first time it is saved, or you want to make sure that some records are not deleted.

6. Converting between real-time and background workflows:
You can change a real-time workflow into a background workflow by choosing ‘Convert to a background workflow’ on the toolbar.
You can change a background workflow into a real-time workflow by choosing ‘Convert to a real-time workflow’ on the toolbar. If the background workflow uses a wait conditions it will become invalid and you won’t be able to activate it until you remove the wait condition.

7. Initiating real-time workflows before or after status changes:
When you configure ‘Options for Automatic Processes’ for real-time workflows, the ‘Start When’ options for the status changes event let you select ‘After’ or ‘Before’ for when status changes. The default option is ‘After’.
When you select ‘Before’ you are saying that you want the logic in the workflow to be applied before data changing the status is saved. This provides you with the ability to check the values before other logic has been applied after the operation and prevent further logic from being performed. For example, you may have additional logic in a plugin or custom workflow action which could initiate actions on another system. By stopping further processing you can avoid cases where external systems are affected. Applying real-time workflows before this event also means that other workflow or plug-in actions in Microsoft Dynamics CRM that may have saved data don’t need to be “rolled back” when the operation is canceled.

8. Using the Stop Workflow action with real-time workflows
When you apply a ‘Stop Workflow’ action in a workflow you have the option to specify a status condition that can be either ‘Succeeded’ or ‘Canceled’. When you set the status to canceled, you prevent the operation. An error message containing the text from the stop action status message will be displayed to the user with the heading ‘Business Process Error’.

Reports in Dynamics CRM 2013

Microsoft Dynamics CRM 2013 includes reports that provide useful business information to the user. These reports are based on Microsoft SQL Server Reporting Services, and provide the same set of features that are available for the Microsoft SQL Server Reporting Services reports. The report definition (data and layout) of Microsoft Dynamics CRM reports are contained in an .rdl file, and the contents of the .rdl file conform to the Microsoft SQL Server Report Definition Language Specification.

1. System Reports (Out-of-box Reports):

Dynamics CRM 2013 comes with 25 out-of-box reports for viewing your business data. The following table shows a list of available reports and what data they get when you run.

Name Description
Account Distribution Identify patterns in top revenue-generating accounts.
Account Overview View a one-page overview of an account.
Account Summary View a chronological summary of an account.
Activities Display a list of activities.
Campaign Activity Status Track campaign activities.
Campaign Comparison Compare two campaigns.
Campaign Performance Track the progress and status of campaigns.
Case Summary Table View the patterns in cases.
Competitor Win Loss Compare how your sales team performs against competitors.
Invoice View an invoice and its line items.
Invoice Status View your accounts receivable.
Lead Source Effectiveness Compare your lead sources.
Neglected Accounts Identify accounts that have not been contacted recently.
Neglected Cases Identify cases that have not been contacted recently.
Neglected Leads Identify leads that have not been contacted.
Order View an order and its line items.
Products By Account View products that are used by an account.
Products By Contact View products that are used by a contact.
Progress against goals View progress against goals
Quote View a quote and its line items.
Sales History Understand past sales performance.
Sales Pipeline View anticipated potential sales.
Service Activity Volume View the patterns in service activity volume.
Top Knowledge Base Articles Identify the most frequently used knowledge base articles.
User Summary View user contact and security role information.


2. Custom Reports:

You can also create custom reports in Dynamics CRM 2013, there are two types of custom reports you can create in Dynamics CRM 2013: Fetch-based and SQL-based.

Fetch-based: Fetch-based custom reports use FetchXML queries, which are proprietary to Microsoft Dynamics CRM, to retrieve data for reports. These reports are introduced in Microsoft Dynamics CRM 2011 and use FetchXML queries to retrieve data for reports. You can deploy custom fetch-based reports to Microsoft Dynamics CRM Online and to on-premises Microsoft Dynamics CRM 2011. All reports that are created using the Report Wizard in the Microsoft Dynamics CRM 2011 are Fetch-based reports. You can deploy custom Fetch-based reports to Microsoft Dynamics CRM Online and On-Premises.

SQL-based: These reports use SQL queries to securely retrieve data for reports from filtered views defined by the system. These are the same reports that have been available for previous versions of Microsoft Dynamics CRM. The default reports that are shipped with Microsoft Dynamics CRM 2011 are SQL-based reports. You cannot deploy custom SQL-based reports to Microsoft Dynamics CRM Online.

Use SQL and filtered views to retrieve data for reports: Microsoft Dynamics CRM data and metadata are stored in a Microsoft SQL Server database named <organization_name>_MSCRM on the server that is running Microsoft SQL Server in the Microsoft Dynamics CRM installation. SQL-based reports in Microsoft Dynamics CRM use the filtered views provided for each entity to retrieve data for the reports. Filtered views are fully compliant with the Microsoft Dynamics CRM security model. When you run a report that obtains data from filtered views, the Microsoft Dynamics CRM security role determines what data you can view in the report. Data in filtered views is restricted at these levels: the organization, the business unit, the owner, and at the field level.

Filtered views exist for all Microsoft Dynamics CRM entities, including custom entities. Your custom SQL-based reports cannot read data directly from the Microsoft Dynamics CRM database tables. Instead, you must use the filtered views to retrieve data for your custom SQL-based reports.

The following sample SQL code returns all columns from the filtered view for an Account entity:

SELECT * FROM dbo.FilteredAccount

Filtered views also provide a way to pull Microsoft Dynamics CRM report data into Microsoft Office applications, such as Microsoft Office Excel and Microsoft Access. For a complete listing of all the standard filtered views organized by product area

Differences between the RDL File of SQL-based and Fetch-based reports: The following table lists the differences between .rdl files of SQL-based and Fetch-based reports in Microsoft Dynamics CRM.

SQL-based Report Fetch-based report
The <DataProvider> element value in the .rdl file is set to SQL. For example:


The <DataProvider> element value in the .rdl file is set to MSCRMFETCH. For example:


The query specified for retrieving data is in the <CommandText> sub-element under the <Query> element in the report definition (.rdl file) is a SQL query. For example, the query for retrieving all account names for a SQL-based report will be:

<CommandText>SELECT name FROM FilteredAccount;</CommandText>

The query specified for retrieving data is in the <CommandText> sub-element under the <Query> element in the report definition (.rdl file) is a FetchXML query. For example, the query for retrieving all account names for a Fetch-based report will be:

<CommandText><fetch version=”1.0″ output-format=”xml-platform” mapping=”logical”><entity name=”account”><attribute name=”name” /> </entity></fetch></CommandText>

Import, update, and export solutions in Dynamics CRM 2013

How often you import, update, or export solutions may depend on the size of your organization, your internal development practices, and whether you are developing a solution that is to be distributed as a managed solution.

  • If you have a small organization with few customizations, and you’re the only customizer, you may never export or import solutions except to periodically export the default solution to create a backup or if you choose to use or buy a managed solution provided by someone else.
  • Some organizations will have an outside company create customizations for them. In this case, they’ll export any customizations that they currently have and send them to the outside company. That company will develop and test customizations and send them back to the organization to be imported.
  • Large organizations may have several teams of people customizing the system. They may have a separate organization just for development and customizations. These organizations frequently also have a separate test organizations and a UAT (User Acceptance Testing) organizations in addition to a production organization which everyone in the organization actually uses. These organizations depend on exporting and importing customizations from one organization to the next in the process of creating, testing, and verifying the solutions.

The strategy you choose should depend on your needs. Some important things to keep in mind:

  • You can’t export your default solution as a managed solution.
  • We don’t support importing a default solution taken from an on-premise deployment into a CRM Online organization or a default solution taken from a CRM Online organization into an on-premises deployment. We do support importing custom solutions between these deployment types, but not default solutions.
  • Custom solutions developed using Microsoft Dynamics CRM 2011 can be imported into Microsoft Dynamics CRM 2013 and Microsoft Dynamics CRM Online organizations.
  • Custom solutions developed using future versions of Microsoft Dynamics CRM cannot be installed into earlier versions without first being ‘down-leveled’ to match the earlier version.
  • When you export a managed solution, you can’t import it back into the organization it was imported from.
  • Only export a solution as a managed solution when you intend to distribute it.
  • Never import an unmanaged solution unless you are sure you want to accept all the customizations in it and allow any of those customizations to overwrite any customizations you previously created.
  • Solutions can’t delete anything. Importing an unmanaged solution might overwrite existing customizations, but it can’t entirely remove them. For example, if you create a custom field for an entity, and then import a solution containing the definition of that entity that doesn’t have the custom field, the custom field you created will still be there. Also, any changes defined within the solution you imported will be there.
  • You can’t import a custom entity with the same name as an existing entity. Microsoft Dynamics CRM allows duplicate display names, though.
  • You must have the System Administrator security role to import security roles, organization settings, sdk message processing steps, and plug-in assemblies.
  • If you import customizations that include a language that is not installed on your system, any labels defined in the customizations will default to the base language of the Microsoft Dynamics CRM system the customizations were imported from.
  • All imported security roles will be attached to the root business unit.
  • If an imported security role originated from the same CRM system, any changes applied to the security role will be merged. All privileges on system entities for the security role will be replaced by privileges defined by the security role that is being imported.

1. Import Solutions:

You can import solutions manually using the steps below. Only import solutions that you’ve obtained from a trusted source. Customizations might include code that can send data to external sources.
1. Navigate to Settings -> Solutions.
2. In the solutions list menu choose Import.
3. In the Import Solution dialog, Select Solution Package step browse to the compressed (.zip or .cab) file that contains the solution you want to import.
4. Click Next
5. You can view information about the solution before you click Import.
6. You may need to wait a few moments while the solution import completes. If it is successful, you can view the results and click Close.
If you have imported any changes that require publishing, you must publish customizations before they will be available.

If the import isn’t successful, you will see a report showing any errors or warnings that were captured. You can click Download Log File to capture details about what caused the import to fail. The most common cause for a solution import to fail is that the solution did not contain some required solution components.

When you download the log file, you will find an XML file that you can open using Microsoft Office Excel and view the contents.

2. Update Solutions:

There are times when you may wish to install an update to an existing managed solution. The procedure is similar to installing a new managed solution, except you will get some different options. If you are updating a solution you got from someone else, you should get guidance from the solution publisher about which options you should choose.

1. Navigate to Settings -> Solutions.
2. In the solutions list menu choose Import.
3. In the Import Solution dialog, Select Solution Package step browse to the compressed (.zip or .cab) file that contains the solution you want to update.
4. Click Next
5. You can view information about the solution before you click Next. This page will display a yellow bar saying This solution package contains an update for a solution that is already installed.
6. You will have the following options:

  • Maintain customizations (recommended): Selecting this option will maintain any unmanaged customizations performed on components but also implies that some of the updates included in this solution will not take effect.
  • Overwrite Customizations: Selecting this option overwrites any unmanaged customizations previously performed on components included in this solution. All updates included in this solution will take effect.

Choose the appropriate option and then click Next.
7. You may need to wait a few moments while the solution import completes. If it is successful, you can view the results and click Close.
 If you have imported any changes that require publishing, you must publish customizations before they will be available.

Solution publishers may ask you to export your existing unmanaged customizations, update their managed solution using the option to overwrite customizations, and then re-import your unmanaged customizations. This will help ensure that the changes they are expecting are applied while preserving your customizations.

3. Export Solutions:

We recommend that you export your unmanaged customizations periodically so that you have a backup in case anything happens. You cannot export managed solutions.

1.    Navigate to Settings -> Solutions.
2.    In the list select the solution you want to export and click Export.
3.    In the Publish Customizations step you will be reminded that only published customizations are exported and you will have the option to Publish All Customizations before you click Next.
4.    If your solution contains any missing required components you will see the Missing Required Components step. You can disregard this warning only if you intend to import this as an unmanaged solution back into the original organization. Otherwise, follow the instructions in the dialog to cancel the export and add the required components.
5.    In the Export System Settings (Advanced) step you can choose certain system settings to include in your solution. If your solution depends on any of the groups of system settings, select them and click Next. See Settings options for solution export for details about the settings that will be included with each option.
6.    In the Package Type step, you must choose whether to export the solution as an Unmanaged or Managed solution.
7. Click Export to download the solution file.

The exact behavior for downloading files varies between browsers.

 4. Settings options for solution export: The following table shows the options available when you export a solution, based on your selection following system settings will be applied when solution is imported.


Group Setting Description
Auto-numbering Campaign Prefix Prefix used for campaign numbering.
Case Prefix Prefix to use for all cases throughout Microsoft Dynamics CRM.
Contract Prefix Prefix to use for all contracts throughout CRM.
Invoice Prefix Prefix to use for all invoice numbers throughout CRM.
Article Prefix Prefix to use for all articles in CRM.
Order Prefix Prefix to use for all orders throughout CRM.
Unique String Length Number of characters appended to invoice, quote, and order numbers.
Calendar Calendar Type Calendar type for the system. Set to Gregorian US by default
Date Format Code Information about how the date is displayed throughout Microsoft CRM.
Date Separator Character used to separate the month, the day, and the year in dates throughout CRM.
Max Appointment Duration Maximum number of days an appointment can last.
Show Week Number Information that specifies whether to display the week number in calendar displays throughout CRM.
Time Format Code Information that specifies how the time is displayed throughout CRM.
Week Start Day Code Designated first day of the week throughout CRM.
Customization Is Application Mode Enabled Indicates whether loading of CRM in a browser window that does not have address, tool, and menu bars is enabled.
Allow Unresolved Address E-mail Send Indicates whether users are allowed to send e-mail to unresolved parties (parties must still have an email address).
Ignore Internal E-mail Indicates whether incoming e-mail sent by internal CRM users or queues should be tracked.
Max Tracking Number Maximum tracking number before recycling takes place
Render Secure Frame For E-mail Flag to render the body of e-mail in the webform in an IFRAME with the security=’restricted’ attribute set. This is additional security but can cause a credentials prompt.
Tracking Prefix History list of tracking token prefixes.
Tracking Token Base Base number used to provide separate tracking token identifiers to users belonging to different deployments.
Tracking Token Digits Number of digits used to represent a tracking token identifier.
General Block Attachments Prevent upload or download of certain attachment types that are considered dangerous.
Currency Format Code Information about how currency symbols are placed throughout CRM.
Currency Symbol Currency Symbol
Full Name Display Order Order in which names are to be displayed throughout CRM.
Is Get Started Pane Content Enabled Get Started Pane was removed with Microsoft Dynamics CRM 2013 and Microsoft Dynamics CRM Online.
Presence Enabled Information on whether IM presence is enabled.
Negative Format Information that specifies how negative numbers are displayed throughout CRM.
Number Format Specification of how numbers are displayed throughout CRM.
Pricing Decimal Precision Number of decimal places that can be used for prices.
Share To Previous Owner On Assign Information that specifies whether to share to previous owner on assign.
Marketing Allow Automatic Response Creation Indicates whether automatic response creation is allowed
Allow Automatic Unsubscribe Indicates whether automatic unsubscribe is allowed.
Allow Automatic Unsubscribe Acknowledgement Indicates whether automatic unsubscribe acknowledgement email is allowed to send.
Allow Marketing E-mail Execution Indicates whether marketing e-
Outlook Synchronization Allow Address Book Synchronization Indicates whether background address book synchronization in Microsoft Office Outlook is allowed.
Allow Offline Scheduled Synchronization Indicates whether background offline synchronization in Microsoft Office Outlook is allowed.
Allow Scheduled Synchronization Indicates whether scheduled synchronizations to Outlook are allowed.
E-mail Send Polling Frequency Normal polling frequency used for sending email in Outlook.
Min Address Synchronization Frequency Normal polling frequency used for address book synchronization in Outlook.
Min Offline Synchronization Frequency Normal polling frequency used for background offline synchronization in Outlook.
Min Synchronization Frequency Minimum allowed time between scheduled Outlooksynchronizations.
Auto-Tag Max Cycles Maximum number of aggressive polling cycles executed for e-mail auto-tagging when a new email is received.
Auto-Tag Interval Normal polling frequency used for email receive auto-tagging in outlook.
Relationship Roles Relationship Role Settings Relationship roles is a feature that was deprecated in Microsoft Dynamics CRM 2011 and replaced with the Connections feature. People who upgraded from Microsoft Dynamics CRM 4.0 could continue using Relationship Roles with Microsoft
ISV Config Service Calendar Appearance Configuration In Microsoft Dynamics CRM 4.0 ISV Config provided all the capabilities to create custom buttons and form navigation capabilities. In Microsoft Dynamics CRM 2011 all these capabilities were moved to other areas leaving behind only the ability to define visual styles for service calendars.

Solutions in Dynamics CRM 2013

1. Solutions:
Solutions exist so that a set of customizations can be purchased, shared or otherwise transported from one organization to another. You can get solutions in the Microsoft Dynamics Marketplace or from an independent software vendor (ISV). A CRM solution is a file that you can import to apply a set of customizations.
If you are just interested in customizing your organization, here is what you need to know about solutions:

  • Creating solutions is optional. You can customize your CRM system directly without ever creating a solution.
  • When you customize the CRM system directly, you work with a special solution called the Default Solution. The Default Solution contains all the components in your system.
  • You can export your Default Solution to create a backup of the customizations you have defined in your organization. This is good to have in a worst case scenario.

2. Solution Components:
A solution component represents something that you can potentially customize. Anything that can be included within a solution is a solution component.
The following is a list of solution components that you can view within a solution:

  1. Application Ribbon
  2. Article Template
  3. Business Rule
  4. Chart
  5. Connection Role
  6. Contract Template
  7. Dashboard
  8. Email Template
  9. Entity
  10. Entity Relationship
  11. Field
  12. Field Security Profile
  13. Form
  14. Mail Merge Template
  15. Message
  16. Option Set
  17. Plug-in Assembly
  18. Process
  19. Report
  20. Sdk Message Processing Step
  21. Security Role
  22. Service Endpoint
  23. Site Map
  24. Web Resource

Most solution components are nested within other solution components. For example, an entity contains forms, views, charts, fields, entity relationships, messages and business rules. Each of those solution components requires an entity to exist. A Field can’t exist outside of an entity. We say that the Field is dependent on the Entity. There are actually twice as many types of solution components as shown in the list above, but most of them are not visible in the application.
The purpose of having solution components is to keep track of any limitations on what can be customized using Managed properties and all the Solution dependencies so that it can be exported, imported, and (in managed solutions) deleted without leaving anything behind.

3. Managed and unmanaged solutions:
A managed solution can be uninstalled after it is imported. All the components of that solution are removed by uninstalling the solution.

When you import an unmanaged solution, you add all the components of that solution into your default solution. You can’t remove the components by uninstalling the solution.

When you import an unmanaged solution that contains solution components that you have already customized, your customizations will be overwritten by the customizations in the unmanaged solution. You can’t undo this.

Note: Install an unmanaged solution only if you want to add all the components to your default solution, and overwrite any existing customizations.

Even if you don’t plan on distributing your solution, you might want to create and use an unmanaged solution to have a separate view that only includes those parts of the application that you have customized. Whenever you customize something, just add it to the unmanaged solution that you created.

You can only export your Default Solution as an unmanaged solution.

To create a managed solution, you choose the managed solution option when you export the solution. If you create a managed solution, you can’t import it back into the same organization you used to create it. You can only import it into a different organization.

4. How solutions are applied:
All solutions are evaluated as layers to determine what your CRM application will actually do. The following diagram shows how managed and unmanaged solutions are evaluated and how changes in them will appear in your organization.
Starting from the bottom and working up to top:

– System solution:  The system solution is like a managed solution that every organization has. The system solution is the definition of all the out-of-the box components in the system.

– Managed Solutions:  Managed solutions can modify the system solution components and add new components. If multiple managed solutions are installed, the first one installed is below the managed solution installed later. This means that the second solution installed can customize the one installed before. When two managed solutions have conflicting definitions, the general rule is “Last one wins”. If you uninstall a managed solution, the managed solution below it takes effect. If you uninstall all managed solution, the default behavior defined within the System solution is applied.

– Unmanaged Customizations: Unmanaged customizations are any change you have made to your organization through an unmanaged solution. The system solution defines what you can or cannot customize by using Managed properties. Publishers of managed solutions have the same ability to limit your ability to customize solution components that they add in their solution. You can customize any of the solution components that do not have managed properties that prevent you from customization them.

– Application Behavior: This is what you actually see in your organization. The default system solution plus any managed solutions, plus any unmanaged customizations you have applied.

– Managed properties: Some parts of Microsoft Dynamics CRM can’t be customized. These items in the system solution have metadata that prevents you from customizing them. These are called managed properties. The publisher of a managed solution can also set the managed properties to prevent you from customizing their solution in ways they do not want you to.

– Solution dependencies: Because of the way that managed solutions are layered some managed solutions can be dependent on solution components in other managed solutions. Some solution publishers will take advantage of this to build solutions that modular. You may need to install a ‘base’ managed solution first and then you can install a second managed that will further customize the components in the base managed solution. The second managed solution depends on solution components that are part of the first solution.

CRM tracks these dependencies between solutions. If you try to install a solution that requires a base solution which is not installed, you will not be able to install the solution. You will get a message saying that the solution requires another solution to be installed first. Similarly, because of the dependencies, you cannot uninstall the base solution while a solution which depends on it is still installed. You have to uninstall the dependent solution before you can uninstall the base solution.

Every solution has a Publisher. The default solution has a publisher named “Default Publisher for <your organization name>”.

– Solution publisher: The publisher record contains a Prefix value. The default value of this prefix is “new”. When you create new solution components this prefix will be appended to the name. This is a quick way that allows people to understand what solution the components are part of.

Before you start customizing the system we recommend that you change the Prefix value for the default publisher to something that identifies your company.

To change the Solution Publisher Prefix for the default publisher:

1. Navigate to Settings -> Customizations.
2. Select Publishers.
3. If there is more than one publisher, open the one with the Display Name that starts with Default Publisher for <your organization name>.
4. At the bottom of the form update the Prefix field to change the default value of ‘new’ to something that identifies your organization.
5. When you change the value, make sure to tab to the next field. The Option Value Prefix will automatically generate a number based on the customization prefix. This number is used when you add options to option sets and provides an indicator of which solution was used to add the option.

5. Publishing customizations:
Certain customizations that make changes to the user interface require that they be published before people can use them in the application. Publishing provides a way for you to save your work before you have finished and then come back and finish at a later time. Publishing is only required when you change a solution component. When you create or delete a solution component publishing occurs automatically. Before you export a solution you will be prompted to publish customizations. This is because any unpublished customizations will not be included in the solution.

When you perform customizations that will appear in Microsoft Dynamics CRM for tablets you should always explicitly publish your customizations to make sure that every item is synchronized with the CRM for tablets application.

Note: Publishing customizations can interfere with normal system operation. In a production environment we recommend that you schedule publishing customizations when it’s least disruptive to users.
The following solution components require publishing when they are updated:

  • Application Ribbon
  • Entity
  • Entity Relationship
  • Field
  • Form
  • Message
  • Option Set
  • Site Map
  • Web Resource

Entity options in Dynamics CRM 2013

Entity options that can only be enabled: The following screenshot and table lists the options that you can enable for an entity, but after these items are enabled, they can’t be disabled:


Option Description
Business process flows Create business process flows for this entity.
Notes Append notes to records for this entity. Notes include the ability to add attachments.
Activities Associate activities to records for this entity.
Connections Use the connections feature to show how records for this entity have connections to records of other entities that also have connections enabled.
Sending e-mail (if an e-mail field does not exist, one will be created) Send emails using an email address stored in one of the fields for this entity. If a Single Line of Text field with format set to email doesn’t already exist for this entity, a new one will be created when you enable sending email.
Queues Use the entity with queues. Queues improve routing and sharing of work by making records for this entity available in a central place that everyone can access.

Enable or disable entity options: The following screenshot and table lists the entity options that you can enable or disable at any time.


Option Description
Primary Image System entities that support images will already have an Image field. You can choose whether to display data in this field as the image for the record by setting this field to [None] or Default Image.
For custom entities you must first create an image field. Each entity can have only one image field. After you create one, you can change this setting to set the primary image.
Mail Merge People can use this entity with mail merge.
Document Management After other tasks have been performed to enable document management for your organization, enabling this feature allows for this entity to participate in integration with Microsoft SharePoint.
Access Teams Create team templates for this entity.
Duplicate Detection If duplicate detection is enabled for your organization, enabling this allows you to create duplicate detection rules for this entity. For information about enabling duplicate detection.
Allow Quick Create After you have created and published a Quick Create Form for this entity, people will have the option to create a new record using the Create button in the navigation pane.
When this is enabled for a custom activity entity, the custom activity will be visible in the group of activity entities when people use the Create button in the navigation pane. However, because activities don’t support quick create forms, the main form will be used when the custom entity icon is clicked.
Auditing When auditing is enabled for your organization, this allows for changes to entity records to be captured over time. When you enable auditing for an entity, auditing is also enabled on all its fields. You can select or clear fields that you want to enable auditing on.
CRM for phones This entity will be available within the Microsoft Dynamics CRM for phones application.
CRM for Tablets This entity will be available using Microsoft Dynamics CRM for tablets. You also have the option to make this entity Read-only in CRM for tablets.
If the forms for an entity require an extension that isn’t supported by CRM for tablets, such as IFRAME or web resource controls, use this setting to ensure that the data for these entities is not editable by people using CRM for tablets.
Reading pane in CRM for Outlook Records for this entity can display in a read-only view in CRM for Outlook.
Offline capability for CRM for Outlook People using Microsoft Dynamics CRM for Outlook can choose to include data from this entity with the data they take offline.
Warning: Each entity that you enable for offline capability directly affects the time required for people to synchronize data when they come back online. This is especially true for people with less powerful computers. Carefully consider if an entity must be available for people while working offline.

Data encryption in Dynamics CRM 2013

Microsoft Dynamics CRM 2013 uses standard 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 CRM Online, all new and upgraded organizations use data encryption.

For on-premises versions of Microsoft Dynamics CRM 2013, data encryption is not active by default for new or upgraded organizations. However, data encryption may be activated at any time.

Microsoft Dynamics CRM users who have the system administrator security role can activate data encryption or change the encryption key after data encryption is enabled in the Settings -> Data Management -> Data Encryption area. After you activate data encryption, you cannot turn it off.



Important: For on-premises versions of Microsoft Dynamics CRM:

  • Changing the encryption key requires SSL configured on the Microsoft Dynamics CRM website.
  • It is a best practice is to change the encryption key once every year.
  • The encryption key is required to activate data encryption when you import an organization database into a new deployment or a deployment that has had the configuration database (MSCRM_CONFIG) re-created after the organization was encrypted. You can copy the original encryption key to Notepad and paste it into the Settings -> Data Management -> Data Encryption dialog box after the organization import is completed.
  • When you re-enter the data encryption key, we recommend that you run the Microsoft Dynamics CRM web application using Internet Explorer to paste the encryption key into the Data Encryption dialog box.

Copy your organization data encryption key:

We strongly recommend that you make a copy of your data encryption key. This is particularly important for on-premises deployments that may need to reactivate data encryption after a redeployment or failure recovery.

Copy an organization data encryption key:

  1. Sign in to Microsoft Dynamics CRM as a user with the system administrator security role.
  2. Go to Settings -> Data Management -> Data Encryption.
  3. In the Data Encryption dialog box, select Show Encryption Key, in the Current encryption key box select the encryption key, and copy it to the clipboard.

Note: If the Microsoft Dynamics CRM website is not configured for HTTPS/SSL, the Data Encryption dialog box will not be displayed. For a more secure deployment, we recommend that you configure the website for HTTPS/SSL. However, if the website is not configured for HTTP/SSL, use a tool that can be used to modify CRM database tables, such as Microsoft SQL Server Management Studio or the Deployment Web Service, open the configuration database (MSCRM_CONFIG), and in the DeploymentProperties table, set DisableSSLCheckForEncryption to 1.

  1. Paste the encryption key in to a text editor, such as Notepad.
  2. As a best practice, save the text file that contains the encryption key on a computer in a secure location on an encrypted hard drive.

Merge Forms in Dynamics CRM 2013

The ability to merge main forms facilitates the upgrade process. Updated user experiences in Microsoft Dynamics CRM 2013 include new layouts and functionality in forms. This topic explains how you can merge existing forms to use the new layout optimized for this release.


1. What to expect when you upgrade:

We understand that changes that occur during an upgrade can be disruptive and we have designed the form upgrade process to minimize this. Rather than force each organization to adopt all the changes and new features included in this release, we have designed a process to put you in control. People in your organization should be able to continue working with the system while you apply changes to allow them to use new capabilities.

Organizations who upgrade to Microsoft Dynamics CRM 2013 and Microsoft Dynamics CRM Online will be in two main groups:

  • Online organizations: Microsoft Dynamics CRM Online organizations using the Microsoft Dynamics CRM December 2012 Service Update who are upgrading to Microsoft Dynamics CRM Online Fall ‘13.
  • On-premises organizations: Microsoft Dynamics CRM 2011 on-premises organizations who are upgrading to Microsoft Dynamics CRM 2013.

When On-premises organizations are upgraded, they will continue to use the same main form definitions that they had before upgrading. Each entity has a main form named ‘Information’. They will also have some new forms added, but these forms will be in an inactive state so that people using the system will not be able to use them until they are activated. These new forms are named after the entity. For example, the Opportunity entity will have a new disabled ‘Opportunity’ main form and the pre-existing Opportunity ‘Information’ main form will remain active.

Online organizations already have updated main forms for the Contact, Opportunity, Lead, Account, and Case entities that follow the convention where they are named after the entity. When these organizations are updated to Microsoft Dynamics CRM Online Fall ‘13, these main forms will automatically be updated to use the latest form capabilities. These forms will remain active. For entities other than the Contact, Opportunity, Lead, Account, and Case entities, new main forms named after the entity will be added but will not be activated.

Note: If you are a CRM Online organization and you have customized any of the five updated forms, depending on the specific customizations you have applied, you may see a Conflicts tab added to your form. In this tab you will find any fields where the customizations could not be automatically merged into the new layout. To address this, simply edit the form and drag the fields to where you want them to be. Then delete the Conflicts tab.

After you upgrade, you can use the new capability to merge your existing main ‘Information’ forms into the new main form definitions. After you are satisfied with the conversion process for each entity, you can activate the new forms and deactivate the old forms.

2. Merging main forms to use the new layout:

You only need to merge forms for Updated Entities that you have customized. You do not need to do this right away, but you will need to do it sometime before the next major release of Microsoft Dynamics CRM.

When you view one of the updated forms using the form editor, you will see a Merge Forms button in the Upgrade group in the Home tab. Use this button and select one of your existing forms and click or tap Add.

At the bottom of the form, you will find the visual elements of the form you selected have been appended to the bottom of the current form. The only difference is that the header and footer elements from the old form will be added as separate tabs containing a section with the contents of each element.

What you can’t see so easily is that all the form script event handlers are also brought in and merged with the new form. There is a limit to the number of event handlers that can be merged. Each form can have up to 50 event handlers. If the total number of event handlers exceeds 50, the action will be canceled. You will need to remove some event handlers from the form you want to merge before you can merge it.

Once the new forms are merged, you need to move any of the form elements from the old form into the new form until all the added elements are gone. Remove any form elements you don’t need.

If your original form has any security roles assigned to it, be sure to apply the same security roles to the new form.

When you are finished, activate the new main form and deactivate the old one.

Activate or deactivate a main form:

1. In the solution explorer, expand the entities node and select the entity with the main form you want to activate or deactivate.
2. Select Forms to view the forms list. If you do not see the form you are looking for, check that the All Forms view is selected.
3. Select the view and, in the toolbar, choose either Activate or Deactivate.
Note: You must have at least one active main form for each entity. If you try to deactivate the only active main form, you will see an error message.
4. You must publish customizations before these settings take effect.

Actions in Dynamics CRM 2013

Actions are a new feature in Microsoft Dynamics CRM 2013. Actions are a type of process that is run by using custom code that uses the Microsoft Dynamics CRM web services. If you are not a developer, or if you haven’t installed some solution that uses actions, you won’t be able to do anything with Actions in Microsoft Dynamics CRM 2013. You cannot call an action from another process except indirectly through a custom workflow activity or plug-in that contains the code to call the action.
However, if you install a solution that uses Actions or if you work with a developer who can write code for one, you will see that Actions is a very powerful feature.

1. Why use actions?

Actions open a range of possibilities for developers and people who compose business logic. Before Actions, the primary way that developers could implement business processes was limited to plug-ins or custom workflows. With these, developers can perform operations composed of verbs like Create, Update, Delete, Assign, and SetStatus. Developers refer to these actions as ”messages”. Each of these messages is based on actions taken on an entity instance. So if the goal of a process is to create a record, then update it, then assign it, there are three separate steps. Each step is defined by the capabilities of the entity – not necessarily your business process.
Actions provide the ability to define a single verb (or message) that matches an operation you need to perform for your business. These new messages are driven by a process or behavior rather than what can be done with an entity. These messages can correspond to verbs like Escalate, Convert, Schedule, Route, or Approve – whatever you need. The addition of these verbs helps provide a richer vocabulary for you to fluently define your business processes. You can apply this richer vocabulary from clients or integrations rather than having to write the action within clients. This also makes it easier because you can manage and log the success or failure of the entire action as a single unit.

2. Configure actions:

You may need to create an action so that a developer will use it in code or you may need to edit an action that was previously defined. Like workflow processes, consider the following:

  • What actions should they perform?
  • Under what conditions should actions be performed?

Unlike workflow processes, you don’t need to set the following options:

  • Start When: Actions start when code calls the message generated for them.
  • Scope: Actions always run in the context of the calling user.
  • Run in the background: Actions are always real-time workflows.

An action also has something that workflow processes don’t have – input and output arguments.

Create actions: Like workflow processes, actions have the following properties in the Create Process dialog.


– Process Name: This property is used to generate a Unique Name by removing any spaces or special characters from the Process Name.
– Category: This property establishes that this is an action process. You can’t change this after you save the process.
– Entity: With actions processes, you can select an entity to provide context for the workflow just like other types of processes, but you also have the option to choose None (global). Use this if your action doesn’t require the context of a specific entity. You can’t change this after you save the process.
– Type: You can use this property to choose whether to build a new action from scratch or to start from an existing template.

Edit actions: You must deactivate processes before you can edit them. You may edit an action process that was created as part of an unmanaged solution or included in a solution installed in your organization. If the solution is a managed solution, you may not be able to edit it. The solution publisher has the option to edit the managed properties so that the action installed with a managed solution can’t be edited.

When an action is saved a Unique Name is generated based on the Process Name. This unique name has the customization prefix added from the solution publisher. This is the name of the message that a developer will use in their code.

When editing an action you have the following options:


– Process Name: After the process is created and the unique name is generated from the process name, you can edit the process name. You may wish to apply a naming convention to make it easier to locate specific processes.
– Unique Name: When an action is saved, a unique name is generated based on the process name. This unique name has the customization prefix from the solution publisher added. This is the name of the message that a developer will use in their code. Don’t change this unique name if the process has been activated and code is in place expecting to call the action using this name.
– Transaction: Generally, processes that support transactions will “undo” (or rollback) the entire operation if any part of them fails. There are some exceptions to this. Some actions developers might do in code initiated by the action might not support transactions. For example, if the code perform actions in other systems that are beyond the scope of the transaction. Those can’t be rolled back by the action running in Microsoft Dynamics CRM. Some messages in the CRM platform don’t support transactions. But everything you can do just with the user interface of the action will support transactions. All the actions that are part of a real-time workflow are considered in transaction, but with actions you have the option to opt out of this.
You should consult with the developer who will use this message to determine whether it must be in transaction or not. Generally, an action should be in transaction if the actions performed by the business process don’t make sense unless all of them are completed successfully. The classic example is transferring funds between two bank accounts. If you withdraw funds from one account you must deposit them in the other. If either fails, both must fail.
– Activate As: Like all processes, you can activate the process as a template and use it as an advanced starting point for processes that follow a similar pattern.
– Define Process Arguments: In this area, you will specify any data that the action expects to start and what data will be passed out of the action.
When a developer uses a message they may begin with some data that they can pass into the message and use. For example, if you want to create a new case record, you may have the case title value that will be passed in as an argument. This would be an input argument.
When the message is finished the developer may need to pass some data that was changed or generated by the message to another operation in their code. These must be defined as an output argument.
Both input and output arguments must have a name, a type, and some information about whether the argument is always required. You can also provide a description.
The name of the message and the information about all the process arguments represent the “signature” for the message. After an action is activated and it is being used in code, the signature must not change. Changing this signature will cause any code that uses the message to fail. The only exception to this may be changing one of the parameters so that it is not always required.
Changing the order of the arguments by sorting them or moving them up or down doesn’t make a difference because the arguments are identified by name, not by the order. Changing the description will not break code using the message.

Action process argument types: The following table describes the action process argument types.

Type Description
Boolean A true or false   value.
DateTime A value that stores date and time information.
Decimal A number value with decimal precision. Used when precision is   extremely important.
Entity A CRM record for the specified entity. When you select Entity, the   drop-down is enabled and allows you to select the entity type.
EntityCollection A collection of entity records.
EntityReference An object that contains the name, id, and type of an entity record   that uniquely identifies it. When you select EntityReference, the drop-down   is enabled and allows you to select the entity type.
Float A number value with decimal precision. Used when data comes from a   measurement that isn’t absolutely precise.
Integer A whole number.
Money A value that stores data about an amount of money.
Picklist A value that represents an option for an OptionSet attribute.
String A text value.

Note: EntityCollection argument values can’t be set in the user interface for conditions or actions. These are provided for use by developers in custom code
– Add Stages and Steps: Actions are a type of process very similar to real-time workflows. All the steps that can be used in real-time workflows can be used in actions. For information about the steps that can be used for both real-time workflows and actions
In addition to the steps that can be used for real-time workflows, actions also have the Assign Value step that is similar to the one used to set variables or input arguments in dialogs. In actions, these can be used only to set output arguments. You can use the form assistant to set output arguments to specific values or, more likely, to values from the record that the action is running against, records related to that record with a many-to-one relationships, records created in an earlier step, or values that are part of the process itself.

3. Configurable messages:

Once an action is defined and activated, a developer can use that message like any of the other messages provided by the Microsoft Dynamics CRM platform. However, a significant difference is that now someone who is not a developer can apply changes to what should be done when that message is used. You can configure the action to modify steps as your business processes change. Any custom code that uses that message does not need to be changed as long as the process arguments do not change.

Workflow processes and plugins continue to provide similar capabilities for defining automation. Workflow processes still provide the capability for a non-developer to apply changes. But the difference is in how the business processes are composed and how a developer can write their code. An action is a message that operates on the same level as any of the messages provided by the Microsoft Dynamics CRM Platform. Developers can even create plugins for Actions.

4. Global messages:

Unlike workflow processes or plugins, an action doesn’t have to be associated with a specific entity. You can define ”global” Actions that can be called on their own.

5. Actions limitations:

For Microsoft Dynamics CRM 2013, Actions can be called only from code. You can’t call an action from a workflow or other process. So for now the most common ways to invoke Actions will be:

  • From code that executes within a plugin or custom workflow.
  • From a command that is placed in the application and executes the operation using JavaScript code.
  • From an integration with another system that uses the Microsoft Dynamics CRM web services.
  • From a custom client application that uses the Microsoft Dynamics CRM web services.

Business Process Flows in Dynamics CRM 2013

Business process flows are a new feature in Microsoft Dynamics CRM 2013. Business process flows use the same underlying technology as other processes, but the capabilities that they provide are very different from other features that use processes.

1. Why use business process flows?

Business process flows provide a guide for people to get work done. They provide a streamlined user experience that leads people through the processes their organization has defined for interactions that need to be advanced to a conclusion of some kind. This user experience can be tailored so that people with different security roles can have an experience that best suites the work they do by using Microsoft Dynamics CRM 2013 and Microsoft Dynamics CRM Online.

Use business process flows to define a set of steps for people to follow to take them to a desired outcome. These steps provide a visual indicator that tells people where they are in the business process. Business process flows reduce the need for training because new users don’t have to focus on which entity they should be using. They can let the process guide them. You can configure business process flows to support common sales methodologies that can help your sales groups achieve better results. For service groups, business process flows can help new staff get up-to-speed more quickly and avoid mistakes that could result in unsatisfied customers.

2. What can business process flows do?

With business process flows, you define a set of stages and steps that are then displayed in a control at the top of the form.

Business Process Flows1

Each stage contains a group of steps. Each step represents a field where data can be entered. People advance to the next stage by using the Next Stage button. You can make a step required so that people must enter data for the corresponding field before they can proceed to the next stage. This is commonly called ”stage-gating”.

Business process flows appear relatively simple compared to other types of processes because they do not provide any conditional business logic or automation beyond providing the streamlined experience for data entry and controlling entry into stages. However, when you combine them with other processes and customizations, they can play an important role in saving people time, reducing training costs, and increasing user adoption.

Business process flows integrated with other customizations:  When you or your user enters data using business process flows, the data changes are also applied to form fields so that any automation provided by business rules or form scripts can be applied immediately. Steps can be added that set values for fields that are not present in the form and these fields will be added to the Xrm.Page object model used for form scripts. Any workflows that are initiated by changes to fields included in a business process flow will be applied when the data in the form is saved. If the automation is applied by a real-time workflow, the changes will be immediately visible to the user when the data in the form is refreshed after the record is saved.

Although the business process flow control in the form does not provide any direct client-side programmability, changes applied by business rules or form scripts are automatically applied to business process flow controls. If you hide a field in a form, that field will also be hidden in the business process flow control. If you set a value by using business rules or form scripts, that value will be set within the business process flow.

System business process flows: Microsoft Dynamics CRM 2013 and Microsoft Dynamics CRM Online include three business process flows. To understand how business process flows work, review these system business process flows:

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

These business process flows are provided so that people who are using Microsoft Dynamics CRM Online and who used the processes that were released with the Microsoft Dynamics CRM December 2012 Service Update will be able to upgrade and continue to use those processes. The processes included in the Microsoft Dynamics CRM December 2012 Service Update were hard-coded and included some capabilities that are not found in the business process flows you can create.

3. Multiple entities in business process flows:

You can use a business process flow for a single entity or span multiple entities. For example, you may have a process that begins with an opportunity, then continues to a quote, an order, and then an invoice, before finally returning to close the opportunity.

You can design business process flows that tie together the records for up to five different entities into a single process so that people using Microsoft CRM can focus on the flow of their process rather than on which entity they are working in. They can more easily navigate between related entity records.

4. Multiple business process flows are available per entity:

Not every user in an organization may follow the same process and different conditions may require that a different process be applied. You can have up to 10 active business process flows per entity to provide appropriate processes for different situations.

Control which business process flow will be applied: You can associate business process flows with security roles so that only people with those security roles can see or use them. You can also set the order of the business process flows so that you can control which business process flow will be set by default. This works in the same way that multiple forms for an entity are defined.

When someone creates a new entity record, the list of available activated business process flows is compared to the business processes flows that the person’s security role will show them. The first activated business process flow in that list is the one that will be applied by default. If more than one active business process flow is available, people can chose Switch Process from the command bar to apply a different process. Whenever someone switches processes, the current process stage will be set to the first stage of the newly applied business process flow.

Each record can have only one business process flow at a time. When any user applies a different process, that process is the one that the next user to view the record will see. If someone’s security roles do not allow them to use a specific business process flow, the current business process flow will be visible, but disabled.

5. Business process flow limitations:

You can define business process flows only for those entities that support them. You also need to be aware of the limits for the number of processes, stages, and steps that can be added.

Entities that can use business process flows: Only entities that use the updated forms can use business process flows. This includes custom entities and the following system entities:




Campaign Activity

Campaign Response









Marketing List


Phone Call


Price List Item


Recurring Appointment

Sales Literature





To enable a custom entity for business process flows, select the Business process flows (fields will be created) check box in the Entity definition.

Note: You cannot undo this action.

Maximum number of processes, stages, and steps: To ensure acceptable performance and the usability of the user interface, there are some limitations you need to be aware of when you plan to use business process flows:

  • There can be no more than 10 activated business process flow processes per entity.
  • Each process can contain no more than 30 stages.
  • Multi-entity processes can contain no more than five entities.

6. Configure business process flows:

Business process flows use the same technology as other types of processes. The process to create them is similar, but configuring them is very different.

Create business process flows:
There are two ways you can view, create, or edit business process flows:
1. Click on  Microsoft Dynamics CRM->Settings -> Processes
Business Process Flows2
2. In the default solution-> using the solution explorer->click on Processes
Business Process Flows3
Like other processes, business process flows have the following properties in the ‘Create Process’ dialog:
Business Process Flows4
Process name: The name of the process does not need to be unique, but it should be meaningful for people who need to choose a process. You can change this later.
Category: This property establishes that this is a business process flow process. You can’t change this after you save the process.
Entity: Choose one of the entities from the list of business process–enabled entities. If you don’t find the entity you expect, make sure the entity has the Business process flows (fields will be created) option set in the entity definition. You can’t change this after you save the process.
Note: Business process flows have a simplified way to reuse existing business process flows as an advanced starting point for new business process flows. When you select Business Process Flow as the Category, there is no option available to set the Type value as you can for other types of processes. Instead, when you open an existing business process flow, you will find a Save As button on the command bar. This will create a new business process flow that is the same as the existing one, except that the text (Copy) will be appended to the name.

After you create a new business process flow, the Create Process dialog box will close and you must find the new process in the list and open it.

Edit business process flows: Once you open a business process flow to edit it, you will see the following page:
Business Process Flows5
If you want to rename the process or add a description, you must click or tap the Expand toggle to view these properties. When you define the logic for a business process flow, you will edit stages and steps, and add additional entities.

Edit Stages: Business process flows can have up to 30 stages. To add a stage, click or tap the (+) icon near the Stages column. To remove a stage, select it and click or tap the X icon on the right edge of the stage. Stages have a label that you can set. The text of the label is always in upper case.

Stages also have a Stage Category. This is optional. Stage category is useful for reports that will group records by the stage they are in. The options for the stage category come from the Stage Category global option set. You can add additional options to this global option set and change the labels of existing options if you want. You can also delete these options if you wish, but we recommend that you keep the existing options. You won’t be able to add the exact same option back if you delete it. If you don’t want them to be used, change the label to ”Do not use”.

Edit Steps:  When you have selected a stage, click or tap the (+) icon near the Steps column to create a new step. To remove a step, select it and click or tap the X icon on the right edge of the step.

Each step has a label set to New Step when you create it. When you set the field for the step, if you haven’t edited the label, the label for the step will change to match the label for the field. Generally, you want the label for the step to match the label for the field. Once you edit the label, it will not change when you change the field.

Add Additional entities: In the Included Entities area, you can select Options to see available options to Add Entity or Close Process Cycle

Business Process Flows6

You can add any of the entities that have one-to-many relationships with the entity selected for the process. After you add an entity, you can select any of the entities that have a one-to-many relationship with that entity. You can add up to five entities, but each entity you add can only proceed to one of the entities that have a one-to-many relationship with the previous entity. If an entity doesn’t have any one-to-many relationships, your only option is to close the process cycle.

Closing the process cycle is always the last stage of the flow. You can close the cycle by using any of the entities in the cycle. This is frequently a step to change the state of the original entity, but you may choose a different entity.

Remove Additional entities: After you have added an additional entity in Options, you will see a new Deleted Last Entity option. Because each entity you add depends on the previous entity, when there are multiple entities, you need to remove them in the reverse order in which they were added.

To make a business process flow available for people to use, you must order the process flow, enable security roles, and activate it.

Set Order: When you have more than one business process flow for an entity, you need to rank the order in which they should be evaluated to be used by default. To open a dialog where you can move business process flows up or down, in the command bar, select Order Process Flow. For new records or records that do not already have a process flow associated with them, the first business process flow that a user has access to is the one that will be used.

Enable Security Roles: People will only be able to use business process flows that are associated to security roles that are associated with someone’s user account. By default, only the System Administrator and System Customizer security roles can view a new business process flow. To set these roles, in the command bar, select Enable Security Roles. You can choose either the Enable for Everyone or Enable only for the selected security roles options. If you choose Enable only for the selected security roles, you can select which security roles will allow access to the business process flow.

Activate: Before anyone can use the business process flow, you must activate it. In the command bar, select Activate to open the Process Activate Confirmation dialog box. After you confirm the activation, the business process flow is ready to use. If a business process flow has errors, you will not be able to activate it until the errors are corrected.

Business Rules in Dynamics CRM 2013

Business Rules is new functionality in Microsoft Dynamics CRM 2013, with Business Rules you can apply form logic without writing JavaScript code. Business rules provide a simple declarative interface to implement and maintain fast changing, commonly used business rules that will be applied to Main and Quick Create forms for both the web application and Microsoft Dynamics CRM for tablets.

What can Business Rules do?:  Business rules allow for a subset of the capabilities provided by form scripts. With Microsoft Dynamics CRM 2013 and Microsoft Dynamics CRM Online, you can define conditions and apply the following actions:

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

Business rules can be set to apply to all Main or Quick Create entity forms or specific Main forms that you choose.  You can transport business rules from one organization to another by including them in a solution and you can install solutions that contain business rules.

Configure Business Rules: First, you need to have the privileges necessary to navigate to Settings > Customization. This typically requires the System Administrator or System Customizer security role. To activate a business rule, you must have the Activate Business Rules privilege.

There are four ways you can view, create, or edit business rules:

1. Solution -> Entity From a solution, such as the default solution, you will find a Business Rules node for all entities.
2. Solution -> Entity -> Field When you view an entity field, you will find a Business Rules node that will show you only the business rules that include this attribute.
3. Form Editor From the form editor, you can use the Business Rules button in the ribbon to show the Business Rules Explorer on the right side. This will show you all business rules that will be applied just for this form. If you create a rule from the form editor, the default scope is for that form.
 4. Form Editor -> Field When you view the properties for a field that is used in a form, you will see a Business Rules tab that shows you the business rules that include this attribute. If an existing rule is similar to a rule you want to make, you can open that rule and use the Save As button to copy an existing rule as a starting point for a new rule.
Set the scope: In the top right of the form, use the Scope field to set the scope for the rule to All Forms or choose any one of the Main forms. You cannot select multiple specific forms. If you choose All Forms, the rule will be applied to all the Main forms and the Quick Create form, as long as the form includes all the fields referenced by the rule. If you create a new business rule by using the form editor, the default scope is just that form.
Configure Conditions:If you want to change an activated business rule, you must deactivate it before you can edit it.
To add a condition, click the + icon and a new condition row will appear with default values set. Enter the field name to set the Field, and then choose the appropriate Operator. Operator options will change depending on the data type of the field.
Conditions are checked whenever any field referenced within the condition changes.
You can chose three different types of conditions:
Field: Use this type to compare the value of one form field with another.
Value: Use this type to compare the value of one form field with a value you enter.
Formula: This option appears only for numerical or date data types. It does not appear for fields that contain text. Use this type to compare the result of a simple calculation that may use either a value in another form field or a value you enter.

When you are finished entering or editing the rule, click or tap the check mark icon to save it or the (X) icon to discard changes. To remove a previously saved condition, place your cursor over the condition and click the pauseǁicon.


Configure Actions: To add an action, click the + icon and you will have the following options:

1. Show error message: Use this action to set an error message on a field if the data within it is not valid. The text you specify for the message will be displayed with an error icon near the field.
The record cannot be saved as long as this message is displayed. After the data in the field has been corrected according to the conditions set in your rule, the message will disappear and the record can be saved.
2. Set field value: Choose the Field and Type. There are three types:
        Field: Use this type to set the value of one form field with the value of another field.
        Value: Use this type to set the value of a form field with a value you enter.
        Formula: This option appears only for numerical or date data types. It does not appear for fields that contain text. Use this type to set the value to the result of a simple calculation that may use either a value in another form field or a value you enter.
3. Set business required:Use this type to change the requirement level for the field. The options are Not Business Required and Business Required. There is no option to set this to business recommended.
4. Set Visibility: Use this type to change whether the field is displayed in the form. The options are Show Field and Hide Field.
5. Lock and unlock field: Use this type to change whether the field is enabled in the form. The options are Lock and Unlock. When the field is locked, people will not be able to edit the value in the field.
After you have defined an action, you can change the order or delete it by using the options available when you place your cursor over the action.
Set the description: Setting a description is optional. It isn’t displayed anywhere else except in the business rule editor. But it is a good idea to include a description of what the rule is supposed to do and why it has been added.

Test and activate business rules: Before anyone can use the business rules you have created, you must activate them. Before you activate them, you should test them. You can test business rules by using the Preview button in the form editor.

Limitations for business rules: Business rules in this release are intended to address common actions. Compared to what a developer can do by using form scripts, business rules have limitations. However, business rules are not intended to replace form scripts.
The primary limitation you may find compared to form scripts is that all conditions in the business rules are evaluated using AND. All the conditions must be true before the actions will be applied. There is no support for OR or Else operators to provide for more complex logic. To apply OR in your conditions, you need to create separate rules for each condition you want to test. This can be done efficiently by using the Save As option and creating separate rules for each condition you want to test.
Here are some other limitations to using business rules:

  • Business rules run only when the form loads and when field values change. They do not run when a record is saved.
  • Business rules work only with fields. Form scripts can interact with other visible elements, such as tabs and sections, within the form.
  • When you set a field value by using a business rule, any OnChange event handlers for that field will not run. This is to reduce the potential for a circular reference, which could lead to an infinite loop.
  • If a business rule references a field that is not present on a form, the rule will simply not run. There will be no error message.
  • Whole Number fields that use the formats for TimeZone, Duration, or Language will not appear in the rule editor for conditions or actions, so they cannot be used with business rules.