Monday, February 29, 2016

Real-Time Workflows in Microsoft Dynamics CRM 2013

Real-Time Workflows in Microsoft Dynamics® CRM 2013


http://www.wipfli.com/BlogPost_MCRM_Blog_011315_RealTimeWorkflows.aspx
 
One of the best new features in Dynamics CRM 2013 is real-time (syncronous) workflows.
 
Prior to CRM 2013, all workflows ran asynchronous, i.e., in the background.  Because of this, if a workflow made changes to data, a user would have to refresh his or her screen to see those changes.  An example of this is a workflow that creates a task; in order to see this newly created activity, the user would either have to refresh the screen or leave the form and return.  Additionally, workflows were only triggered after events occurred.  This is still the case if creating an asynchronous workflow, but sychronous workflows can be triggered prior to some events occurring.
 
Having the ability to immediately see results on the screen, or to trigger workflow prior to events has an impact on the need for Web Resources (JavaScript) and Plug-ins (C#).  Below are directions on how to create a real-time workflow, as well as examples of where this new functionality reduces these type of custom development.
 

How to Create a Real-time Workflow

 
Creating new process workflow
 
General details of new workflow
 
**Please note: Below are close up views of the three steps from the above example.**
 
New workflow close up 1
 
New workflow close up 2
 
New workflow close up 3
 
 

New “Options for Automatic Processes”

Start when:


Trigger
Start when
Record is created
After
Record status changes
Before or After
Record is assigned
Before or After
Record Fields change
Before or After
Record is deleted
Before
 

Execute as


Executes as
Permissions
The owner of the workflow
Runs with the permissions of the person who owns the workflow.
The user who made changes
Runs with the permissions of the person who triggered the workflow.  If the user does not have sufficient permissions to run a particular action, it will not run.
 
 

Considerations when designing real-time workflow:

  • They can be ranked within a stage.
  • They cannot contain delays or waits.
  • Only errors are logged; cannot view process history.  This limits the ability to debug issues.
  • Importing data for entities that have real-time workflows can have a severe impact on system resources.  Real-time workflows trigger whether resources are available or not.

Possible uses of real-time workflows

 
Reduces the need for JavaScript:  Bring in details from a related entity immediately.
 
Workflow Design
 
Setting workflow properties
 
Results
 
Real-time update
 

Pro:
 
  • Results occur immediately without the use of JavaScript programming.
  • Workflow can be developed for less cost than the equivalent Web Resource.
 
Con:
 
  • Processing is done regardless of available resources.
  • This may slow down the performance of the system.
  • May create window errors with missing data.
  • No process history saved.  Cannot easily debug issues.
Alternative:
  • The above example is one where the data being brought in – namely Account Number – will not change.  This is a good use of synchronous workflows.  If the data is something that can change – such as the phone number, address, or primary contact for an account, consider using the “Quick View” form to display the account information in the opportunity form.
 

Reduce the need for a Plugin:  Validate before deleting produce a message prompt that prevents users from creating bad data.

 

Workflow Design
 
Setting workflow properties example
 
Setting workflow properties close up

Results
 
Business process error example
 


Pro:
  • Results occur immediately without the use of a Plugin.
  • Workflow can be developed for less cost than the equivalent Plugin.
 
Con:
  • Processing is done regardless of available resources.
  • No Process History Saved.  Cannot easily debug issues.
Alternative:
  • Remove the ability to delete accounts from all but an administrator role.
 
 
Real-time workflows add the benefit of immediate results and reduce the need of spending time on custom coding.  Depending on the type of synchronous workflows that are set up, there may be an added benefit of preventing users from deleting important data or inputting unneeded data.  Before you create a custom code to help keep only useful data in your CRM system, think about how a real-time workflow can replace that complicated C# coding.  Whether your organization is a new or patron user of Microsoft Dynamics®CRM, try using the tools that Microsoft CRM 2013 provides you.  Start looking into creating real-time workflows to help keep your CRM 2013 system running smoothly and efficiently.

Sunday, February 28, 2016

How to Implement Robust Auto-Numbering Using Transactions in Microsoft Dynamics CRM

How to Implement Robust Auto-Numbering Using Transactions in Microsoft Dynamics CRM


Author’s Note – This was updated in November 2015 to include asynchronous numbering (by request), additional deadlock prevention commentary, and testing against CRM 2015
The primary failing of every auto-number solution for Microsoft Dynamics CRM that I have come across is the ability to ‘guarantee’ a unique number under heavy load across multiple servers, particularly in a CRM Online environment. Depending on the solution you look at, you will find various attempts to solve this problem.  However, all appear to have limitations, and in some cases, the solutions even include a document explaining how to ‘correct’ duplicate values.

Implementing Robust Auto-Numbering Using Transactions in Microsoft Dynamics CRM Online or On-Premise

With the ability (starting in CRM 2011) for Dynamics CRM plugins to execute within the database transaction, we are now able to (in a supported fashion) generate unique number sequences regardless of load and across multiple CRM servers by leveraging the transactional locking behavior of SQL Server, purely within the context of Microsoft Dynamics CRM.
The core solution is similar to any basic auto-number implementation you may find out there. But certain modifications are now added to ensure unique numbers (serialization of transactions by leveraging SQL locking behavior) as well as to limit the potential of deadlocks (store sequence name/GUID cross-reference in a web resource – or other approaches)
Ken-Blog-Post-Photo-1
So the ‘enhanced’ diagram looks like:
(NOTE: The blue outline represents the newly added portions of the process)
  • Create a ‘sequence’ entity to store the various number sequences for your different entities. For example, sequence name (Customer, Opportunity, Invoice, etc) and a ‘sequence’ field to store the current sequence value. (You could also implement prefix/suffix/etc, but that is outside the topic covered here). If you want to share a sequence between multiple entities, just have the plugin use the same sequence name in the Number Request that is created.
  •  Create a ‘Number Request’ entity to store the requests for numbering that are being made. You will want to introduce some process to clean these records up over time. (plugin/workflow/bulk delete/etc)
  • Register a plugin (CRM Plugin 1) on pre-create of all entities you want to be auto-numbered. This plugin can be registered synchronously or asynchronously, so the user does not have to wait for the numbering to complete.
  • In CRM Plugin 1, whenever a new entity is created and triggers the logic, create a new Number Request entity record, containing all the needed information about which record needs to be numbered (entity type, record id, sequence name, field to populate, etc)
  • Register a plugin (CRM Plugin 2) on pre-create of the ‘Number Request’ entity. This plugin must be synchronous to preserve desired transaction behavior. Keep in mind that if CRM Plugin 1 was set to run asynchronously, it’s still ok for CRM Plugin 2 to be synchronous, and the user still will not have to wait for the numbering to complete.
  • Now, in CRM Plugin 2, implement our ‘real’ numbering logic that leverages DB transactions –  check the sequence entity for the current entity’s latest value, use it as the id for the newly created entity record, then increment the sequence value for the current entity type in the sequence entity.Ken-Blog-Post-Photo-2-Large
The ‘catch’ with Microsoft Dynamics CRM has always been that there was not a robust way to guarantee that two entities won’t get the same sequence value, because there is no supported locking mechanism to ‘guarantee’ in all environment types that only one plugin execution will access the sequence value at a time. Prior to CRM 2011, the best solution I have come across was to use a database call to an external DB in the plugin that atomically reads and updates the sequence value for use in the plugin in a stored procedure transaction, but that requires the creation of a custom database, etc, which I would prefer to avoid by using an internal CRM construct, particularly for CRM Online.
The difference is, now that we have the ability to register our plugin in the CRM database transaction, we can do the following in CRM Plugin 2:
  1. Ken-Blog-Post-Photo-3In our sequence entity, create a new ‘dummy’ or ‘lock’ field. This field will be used by the plugin to ‘lock’ the underlying database record which will enforce sequential access to the associated sequence tables that implement the Sequence entity.
  2. Inside the plugin [CRM Plugin 2 from the diagrams] (registered as a pre-create operation):
    • First retrieve the GUID of the sequence record we want to use. This could be done with a web resource storing the values for each of the sequence names and their corresponding GUID (this or another approach needs to be used to prevent deadlocks caused by getting the GUID with an SDK retrieve before the record is locked), or could be obtained by an SDK ‘retrieve’ to search for the sequence record for the current entity type. [strikethrough because this is shown to introduce deadlocks under high load]
    • Now, UPDATE the sequence record’s ‘dummy’/’lock’ value. At this point NO ONE CAN MODIFY THAT RECORD except the current plugin instance – the database will have an update lock owned by the CRM transaction. Since the FIRST operation we perform on the sequence record is an update, we have serialized the process.
    • Since we know that we have ‘locked’ our sequence record, use the CRM SDK to
      • Retrieve the current sequence value via a retrieve using the record’s GUID. We cannot retrieve the current sequence value until AFTER locking the record.
      • Assign the retrieved id to the plugin entity in the context.
      • Increment the id in the sequence entity record.
This will use the database’s built-in locking behavior to ensure that only one transaction will be reading/updating any given sequence at a time, thereby ensuring the uniqueness of your numbering scheme. Furthermore, if your CRM transaction is rolled back, the sequence will NOT be advanced, which will ensure you don’t have ‘gaps’ in the sequence due to numbers being assigned to failed entity creates.
Once the CRM database transaction completes (Entity Creation) that entity’s sequence will be available to the next plugin executing.
My ‘proof’ was to insert a Thread.Sleep(5000) just after the record lock in Step 2b above. If the database does NOT block access, two new Accounts saved at the same time will take the same amount of time (approximately) as they are executed in parallel. If the database IS blocking as expected with the transaction, there should be a 5 second gap between the first Account create and the second (due to the fact that the second account has to wait until the first save is COMPLETE before it can continue. We did observe a 5 second delay between saves, and thus that the expected database locking does occur, and our numbering solution is correct.

Monday, February 22, 2016

Dynamics CRM 2015 – Querying Data with QueryExpression


Dynamics CRM 2015 – Querying Data with QueryExpression



Developers can utilize the power of the Microsoft Dynamics CRM 2011 SDK to build custom applications, plug-ins, and workflows which communicate with the CRM platform. Queries can be written to retrieve information from the CRM database in many different ways. In this blog, I will explain the use of the QueryExpression class and see how it can be used to write simple and complex queries.
QueryExpression is useful in scenarios where you want to return multiple entities that match a certain criteria. It lets you specify which fields you want to have returned (from the specified entity type or any related entity) as part of the query result in order to improve performance. Developers can also control the order in which records are returned.
To illustrate the power of QueryExpression, let’s take a look at a few examples:
Example 1 – Simple query with two conditions for a single entity
Scenario: Retrieve the First Name, Last Name, and Email Address for Contacts that have the Job Title field set and live in Auckland city

Dynamics CRM 2011 Querying Data with QueryExpression
Example 2 – Complex query with multiple conditions across two related entities
Scenario: Retrieve the First Name, Last Name, and Email Address for Contacts that are “Sales Managers” and the Parent Customer is based in Auckland or Wellington city

Dynamics CRM 2011 Querying Data with QueryExpression
Example 3 – Simple query with OrderExpression
Scenario: Retrieve all Accounts in the system and order by the date created (most recent first) 
Dynamics CRM 2011 Querying Data with QueryExpression
Those are just a few examples of how you can write queries using QueryExpression. Developers can use any combination of LinkEntity, ConditionExpression and OrderExpression to write complex queries.

CRM Scenarios

Using Queues in Microsoft Dynamics CRM

Using Queues in Microsoft Dynamics CRM
(https://redcrm.wordpress.com/2015/05/14/using-queues-in-microsoft-dynamics-crm/)
Queues can be instrumental in helping to organise, prioritise, and monitor the progress of your work, such as Cases while you are using Microsoft Dynamics CRM. If used properly they can act as a centralised location for users to manage case progress, respond to service calls or work with prospects in your sales pipeline. There is often times when the feature is overlooked or misunderstood, however as the functionality was updated around the use of queues in MS Dynamics CRM 2013 SP1 and 2015 there is a lot more to do with queues and it is not as difficult as you may think.
Recently I published a blog post on the use of Routing Rules in CRM 2015 and CRM Online and during the process referenced the Queue entity. So I thought I would expand a little. At a high level what you may or may not know is that queues;
  • Can be used with any custom entity
  • Can be made “Public” or “Private” (with Private queues making the queue items only available to members)
  • Private queues are auto-created for new users or teams when they are created
  • Queues can actually contain multiple entity types, (e.g. tasks, emails, cases)
  • Users can work on Queue Items to prevent task duplication
  • Queues can be workflow enabled
  • Queues cam ne enabled for auditing
Public or Private? In CRM there is an attribute called “QueueViewType” which is used to define if a queue is public or private. Private uses have individual members (users) which are used to allow/remove access to the queue. You can add a team to a private queue and this will add all the team members as members of the private queue. Some other things to remember about queues are that;
  • All user queues are private, so only the user will be able to see queue items in this queue
  • Team queues are marked as private by default, the team owner and all its members have access to the queue
  • All other queues are considered public, anyone with ‘read’ access to queues can see them
For information on CRM queues in previous versions check this MSDN article;https://msdn.microsoft.com/en-us/library/gg328459(v=crm.5).aspx
Creating a Public Queue:
Creating queues are simple enough in CRM, as mentioned above each user account has it’s own private queue created automatically. The ability to create a queue will be based on the users security role, out of the box the following roles can create a queue;
  • Customer Service Manager
  • System Customizer
  • System Administrator
If you have an applicable role with create permissions then you are good to go – if you are not sure you can check your role by using the steps in this Customer Centre article; http://www.microsoft.com/en-us/dynamics/crm-customer-center/view-your-user-profile.aspx
Next go to; Settings > Service Management/Business Management* > Queues, then choose New. You will then need to complete the required fields in the Queue form, out of the box these fields will be;
  • Name
  • Type (Public or Private)
  • Owner (Lookup to System User)
  • Convert Incoming Email To Activities
The “Incoming Email” field is for exactly that purpose, here you can enter the email address that receives all messages for this queue, for example; ‘info@myorganisation.com’.
In the “Convert Incoming Email to Activities” field you will need to make sure you choose the appropriate action, by default this will likely be populated with “All email messages“, this will not be suitable for everyone. Depending on the purpose of the queue you may want to only covert emails that are “Email messages in response to a CRM email” or only emails from Leads, Accounts and Contacts.
The locked field referring to “Mailbox” will be automatically populated with a new mailbox record when you have created the Queue, once this has occurred you can update the mailbox details using the link.
Finally, click Save.
*Service Management will be visible in the Settings area of CRM based on the version you are using.
Queue_Create
Queue Items:
Queue items are displayed in the associated sub-grid within the Queue form. If you are using Cases for your solution then all cases that are either; (a) routed to this queue (using routing rules) or (b) manually assigned cases will be displayed.
It is worth noting that a queue item is automatically deactivated if the associated record is updated from Active to Inactive, which applies as you’d expect to all queue enabled entity records that have Active or Inactive states in CRM.
Create an Automatic Case Creation Rule;
Automatically creating cases from incoming email can be awesome for reducing the amount of manually created cases in CRM and increasing the actual contact time of a support desk and your agents for both internal and external channels. Case creation rules use conditions similar to those found in Advanced Find to automatically convert emails into support cases.
Please Note; This functionality applies to MS Dynamics CRM Online that were either updated to CRM 2013 SP1 (or Spring ’14 release as it is known) or the CRM 2015 product update. If your deployment is On Premise you will also need to have updated to CRM 2013 Sp1 or CRM 2015.
Step 1 – Create a New Record
To create a new Case Creation Rule in CRM 2015 click the “Email to Case Settings” button in the ribbon from your Queue (as created in the above steps). The create window will pop a new Case Creation Rule form, complete the required fields, which include;
  • Name
  • Source Type (Email)
  • Queue (Lookup to your Queue)
  • Owner
Now, you can only associate one rule per source type, so in this example once we have selected the “Source Type” as “Email” in a rule for this queue, we cannot have another active rule associated unless it is used for Social Monitoring. Also, make sure your queue has an email address as per the previous section.
Case_Creation_Rule1
Step 2 – Specify Conditions
Next you will need to go to the “Specify Conditions for Case Creation area in the next section of the form and choose your condition or conditions (as you can add multiple). These include;
  • Create cases for email from unknown senders+
  • Create case if a valid entitlement exists
  • Create cases for activities associated with a resolved case
  • Create case when the case associated with the activity is resolved since
Create Cases for email from unknown senders – if you select this option all emails from unknown senders (i.e. a sender that cannot be associated with an email in a CRM record) are converted to a case, be default this will also create a contact record. However this does work in conjunction with the personal options for“Automatically Create Records” set by the user that owns the rule.
+If this option is not selected cases will only be created automatically for email senders that are attributed to an Account or Contact in CRM, (those email addresses associated to other records will not create a case).
Create case if a valid entitlement exists – if you select this option then the rule will do exactly that, to read more on entitlements see;https://msdn.microsoft.com/en-us/library/dn689025.aspx. If the sender of the email is a contact that has a parent account with a valid entitlement and the contact is associated using the sub-grid on the entitlement, then a case is created, this is also true if the entitlement sub-grid is empty as the entitlement can be applied to all contacts for that account.
Create cases for activities associated with a resolved case – a case will be created if the email is related to a resolved case if it references an active case then no case is created. If you select this option then the option for Create case when the case associated with the activity is resolved since appears which allows you to select/define a duration. This will mean that a new case will be created only if it is resolved earlier than the specified duration. If it is later then it is associated with the existing resolved case.
When you are done click “Save”.
Step 3 – Specify Case Details
Now we need to add conditions for the creation rule, for those users familiar with Advanced Find it is as easy as that. We also need to add the case properties for the records we are going to work with once created, such as the priority etc.
In this step you can define how to treat cases based on their customer category or the contact type, a good tip is to be sure that you use the correct reference in the conditions, for example, for Contacts it is; “Sender (Contact)”, for Accounts the reference is; “Senders Account(Account)”. You add conditions by clicking the “+” icon near for “Condition”.
Case_condtitions
Once you are done click “Save” and if you are happy click “Activate”.
Please Note; Once a case is created the incoming email is removed for your Queue. If there are no routing rules to apply to the newly created case to a user or Queue then the case owner will be set to the user that owns the case creation rule.
Hope this helps, if you need to dig deeper check out the CRM Customer Centre, or for technical information such as case creation from a web service see MSDN. Happy CRM’ing!

Thursday, February 18, 2016

Workflow Utilities

There are some workflows utilities that could be useful for your implementation:

MSCRM ToolKit: http://mscrmtoolkit.codeplex.com/
MSCRM ToolKit is a collection of useful tools for people working on Microsoft Dynamics CRM 2011, 2013 and 2015 projects.

It is built around features described in the Microsoft Dynamics CRM 2015 Software Development Kit.

In the toolkit you can find the following tools:

Reference Data Transporter

Tool for transporting reference data between different CRM deployments.

N:N Associations Transporter

Tool for transporting N:N associations between different CRM deployments.

Data Export Manager

Tool for exporting data from CRM deployment. Exporting data into different formats: XML, XML Spreadsheet 2003, CSV.

Export Entities Structure

Tool for exporting the Metadata (entities, attributes, relationships and diagrams) from CRM.

Deployment Properties (On-Premise only)

Tool for changing the server and deployment properties for an On-Premise CRM deployment.

Solutions Transporter

Tool for transporting solutions between different CRM deployments.

Solutions Import Jobs Viewer

Tool for viewing the Solutions Import jobs in a CRM deployment.

Workflow Execution Manager

Tool for executing workflows on the CRM.  community.dynamics.com/.../step-by-step-running-on-demand-workflow-for-all-active-records

Records Counter

Tool for counting records in the CRM deployment.

Audit Export Manager

Tool for exporting Audit Details from the CRM.

CRM Email Workflow Utilities crmemailworkflowutilities.codeplex.com

Custom workflow actions that deal with emails in Dynamics CRM 2011, 2013, & 2015

Email Business Unit

CC Business Unit

Email Security Role

CC Security Role

Email Team

CC Team

Delete Email Attachments without delete email

Delete Email Attachments By Name

Send Draft Email

Dynamics CRM 2015 Workflow Tools msdyncrmworkflowtools.codeplex.com

Project Description

This project contains Tools created in WorkFlow Activities to be imported in Dynamics CRM, to use them

All the Source code is included and open.

Right now there are this tools:

Force Calculate Rollup Field

Since Dynamics CRM 2015, we can add Rollup fields. The Rollup fields calculation is an asynchronous process, and with this project, we are giving more possibilities to this calculation.

The idea is to use the Workflows (Sync & Async) with custom workflow Activity, to force this calculation when the user define.

Apply Routing Rules

This Action forces the execution of the active Routing Rules for the Case passed in the parameter

Sharing Record Step

This Action could be used to Share a record to a User or Team (or both).

Query Values Step

This Action could be used to query to another entity with two filters fields, and get up to two fields. Very usefull for example to query a custom entity used with parameters.

Dynamics CRM 2015 Calculate Rollup Field (Workflow Activity) calculaterollupfield.codeplex.com

Project Description

Since Dynamics CRM 2015, we can add Rollup fields. The Rollup fields calculation is an asynchronous process, and with this project, we are giving more possibilities to this calculation.

The idea is to use the Workflows (Sync & Async) with custom workflow Activity, to force this calculation when the user define.

CRM 2011/2015 Distribute Workflow Activity  http://crm2011distributewf.codeplex.com/

Summary

With CRM 2011 out-of-the-box it is possible to perform actions on entities that have a N:1 relationship to a given entity, For example from an opportunity it is possible to update or run a workflow on the parent customer.

This plugin allows to extend this to the other two possible relationships: 1:N and N:N. With the aid of this plugin it is possible to perform an action on each opportunity given the parent customer (1:N) or on each competitor given the opportunity (N:N) or on each opportunity given the competitor (other way of the same N:N).

CRM Numeric Workflow Utilities crmnumericworkflowutilities.codeplex.com

Custom workflow actions that deal with numeric values in Dynamics CRM 2011, 2013, & 2015

Add, Average, Divide, Max, Min, Multiply, Random Number, Round, Subtract, ToDecimal, ToInteger, Truncate

CRM String Workflow Utilities crmstringworkflowutilities.codeplex.com

Custom workflow actions that deal with text strings in Dynamics CRM 2011, 2013, & 2015

Contains, Create Empty Spaces, EndsWith, Join, Length, PadLeft, PadRight, Regex Match, Regex Replace, Replace, StartsWith, Substring, ToLower, ToTitleCase, ToUpper, Trim, Word Count

Wednesday, February 17, 2016

Minimum privileges required to access CRM application

To access CRM application using either Browser or Outlook and perform common tasks all users must be assigned at least one security role with below minimum privileges.

Below is the matrix
Entity Name
Privilege(s)  
Access Level
Security role “Tab” Name
User Entity UI SettingsCreate, Read, WriteUserCore Records
User SettingsReadUserBusiness Management
CustomizationsReadOrganizationCustomization
System FormReadOrganizationCustomization
ViewReadOrganizationCustomization
Web ResourceReadOrganizationCustomization
Below are minimum privileges you need to define for some common tasks
Access CRM using Browser:
  • To render the Home page: prvReadWebResource, prvReadCustomization
  • To render an Entity grid (that is, to view lists of records and other data): Read privilege on the entity, prvReadUserSettings, prvReadQuery
  • To view single Entitie in detail: Read privilege on the entity, prvReadSystemForm,  prvCreateUserEntityUISettings, prvReadUserEntityUISettings
Access CRM using Outlook:
  • To render navigation for CRM and all CRM buttons: prvReadEntity, prvReadQuery
  • To render an Entity grid: Read privilege on the entity, prvReadCustomization, prvReadWebResource, prvReadUserQuery
  • To render Entities: Read privilege on the entity, prvReadSystemForm, prvCreateUserEntityUISettings, prvReadUserEntityUISettings, prvWriteUserEntityUISettings
We can get more information in the Helper page from “Security Role” form (Refer Navigation below).

Below is the link from where it's taken-