Tag: workflow

Enforcing Business Process Flow Fields with Real-time Workflows

Earlier I demonstrated the new capabilities that Microsoft Dynamics CRM 2013 has introduced for workflow processes: showing error messages with real-time workflows. I covered examples of record assignment, merging duplicate accounts and stopping unwanted updates in the Mobile Express client. This time I’ll take a look at how the error message feature can be leveraged in managing the sales process on opportunity records.

The new Business Process Flows in CRM 2013 provide the possibility of setting fields in a stage as required. This is a nice advancement over the previous platform functionality that only allowed you to set fields as business required per entity, since now we can dynamically control the stage at which we will require the user to input the information onto a form. It’s very typical that a user wouldn’t yet have much details available about a sales opportunity when first entering the information into the CRM system, so it makes total sense to not ask too many questions initially. After all, you can make a field required, but if the user simply doesn’t possess the information asked in it, he or she may just enter dummy data into the field to meet the technical minimum requirements.

Looking at the default opportunity sales process that comes with Dynamics CRM, we have a number of bit fields in the Close stage that indicate tasks the opportunity owner should complete before closing the opportunity. In the Business Process Flow editor we can tick a box and set these fields to be required. What does a required field in the Business Process Flow then mean exactly? It simply means that you can’t move the record forward from that stage until a value is entered in the field. In the case of bit fields (two options) the value should be set to Yes (ID 1) to meet the criteria.

OK, sounds logical, but what about if we’re already in the last stage of the process? How is the requirement level enforced if there are no more stages to move to? The answer is: it’s not. Since the actual closure of an opportunity as Won or Lost is not a stage in the process but rather a change of the record status, Business Process Flow has nothing to do with it. We can observe this behavior by setting a field required in a process stage and then navigating to a test opportunity and attempting to close it as Won. In our example, the File Debrief field has been set as required in the Opportunity Sales Process, but the system still allows the user to close the opportunity without entering data into this field.

“That sounds like an unfortunate gap in the business logic, I guess we’ll need to get a developer to write a plug-in for us to stop the status change operation if required data is missing.” Hold it right there, mister! We’re dealing with Dynamics CRM 2013 here, which means we can build the equivalent feature with a real-time workflow process! No custom code needed for such a simple task, as long as you know how to leverage the new interactive nature of synchronous workflows.

Let’s create a new workflow on the opportunity record and set it to start when the record status changes. We’ll configure it to be run as “after” the event, since we’re interested in capturing the new status value of the record. In the workflow criteria we’ll define that we want our business logic to apply if the opportunity is being set as Won but the File Debrief field has not bee set to Completed. Since this is a real-time workflow, we can add a step where we set the process to be stopped as Cancelled and then define an error message in that step’s properties. This will then be presented to the end user who is triggering the status change event if the workflow criteria is met.

Now, let’s go to our test opportunity, re-open it and attempt to close it without marking the File Debrief field as Completed. When clicking the Close as Won button on the opportunity form command bar we’re presented with the standard, non-customizable Close Opportunity dialog window asking us about the Actual Revenue, Close Date and so on. Since we’re so excited about having won the opportunity we’ve completely forgotten that there were still tasks we needed to complete before we’re allowed to close it off from the sales pipeline.

Once we click OK, a new dialog window is presented: the Business Process Error prompt, along with the error message that we defined in the Stop stage of our workflow process. The opportunity close event is rolled back and we can return to the opportunity form to see what steps of the process we had neglected.

As I mentioned in my previous article about the new business process automation capabilities of CRM 2013, Business Process Flows are essentially a process map that is meant to guide the user through the stages. It cannot actually perform any automated tasks by itself, nor enforce any rules apart from the changing of the stage through the visual business process control at the top of the form. To implement this type of functionality you should look into Business Rules and Real-Time Workflows instead.

November 9, 2013
Using Real-Time Workflows to Show Error Messages
In CRM 2013 we now have the option of setting a workflow to be run synchronously, also known as a real-time workflow. This opens up great new possibilities to leverage workflows in designing automated processes and providing immediate feedback to the end user when CRM data is created or updated. Having the workflow process executed in real-time also provides one additional capability that traditional, asynchronous workflows can’t handle: stopping the transaction from taking place.

Configuring Custom Error Messages

Similar to synchronous plug-ins, real-time workflows can present a Business Process Error dialog to the user when the operation being performed is breaking the rules of the configured business logic. As the real-time workflows execute in the current transaction, they have the power to roll back the changes that the user is trying to perform, whereas an asynchronous workflow could only observe what had already taken place.

How does this work in practice? Let’s explore the feature by setting up a very simple workflow rule to verify the owner of a record, in this case the Project Manager (owner) of a custom Project entity. When creating the workflow we’ve unchecked the “run this workflow in the background (recommended)” checkbox and thus defined it to run in real time. (If you forgot to do this, just reach for the “Convert to a real-time workflow” button on the toolbar, as the form checkbox can’t be edited directly). We’ll attach the workflow to the assign event of the entity.

In the workflow rule criteria we’ll perform a check that the Project Manager has the necessary qualifications for the job. If not, we will stop the workflow and set its status to be Canceled. What’s new compared to CRM 2011 workflows is that we can set a Status Message for the workflow cancellation. Rather than just being a behind the scenes log entry, this text field’s contents will actually be presented to the user if the real-time workflow process is cancelled. This is therefore the place where you should provide instructions on why the cancellation took place and how the user can avoid it.

Let’s activate our workflow, go to an existing project record and attempt to assign it to a less competent CRM project manager, like Teppo:

After we click OK on the assign dialog, a Business Process Error dialog is presented, along with our status message text that explains why the operation cannot be allowed.

The transaction is rolled back, which means the assignment never takes place and our project remains in the hands of a certified professional. CRM workflows save the day!

Here’s a couple of considerations to keep in mind with the above example:
- If I had set the workflow to run Before the assign event, I wouldn’t have received an error. That’s because we would have had a pre-image of the record to work with, in which the change of ownership would not yet have taken place. Having these options available in the workflow editor UI gives more flexibility for defining the business logic, but you should know at least a bit about the underlying Dynamics CRM event execution pipeline to make the most of them.
- If I had simply clicked on the Project Manager (owner) lookup and changed the value, I wouldn’t have received an error in either case. That’s because from the platform’s perspective the assign event is different from the event of updating the owner lookup field. Also note that creating a new record for another user is not an assign event either, so you’ll want to expand the criteria of when the workflow rule is triggered to catch these.
Stopping Unwanted Data Updates

What kind of real life scenarios would then require the system to throw a Business Process Error at the user? Let’s think about a typical CRM implementation where the customer data is integrated with an ERP system. As long as you’re working with prospects that haven’t placed an order yet, there shouldn’t be too many limitations in place in CRM on how you can update the data. Once the account information is transferred to the ERP system for the purpose of order and invoice processing, the need for restricting certain operations on the account records will likely arise.

Let’s assume that we’re identifying the ERP integrated accounts through the Account Number field on the CRM account entity. If the field contains data, then this is a record where updates need to be restricted. By leveraging the new CRM 2013 Business Rules we can configure the fields on the form to be disabled if an account number exist. But what about updates that are not performed as changes of form field values? This is an area the Business Rules can’t touch, but with real-time workflows we may be able to add custom business logic into CRM that would have traditionally required a .NET developer to write plug-ins for us.

As an example, we’d like to ensure that no account records can be deactivated in CRM if they exist in the ERP system. The deactivation might take place through a data management operation like merging duplicate records, in which the master record is left in active status and the child record gets deactivated. We can’t directly trigger the workflow process from the clicking of the Merge button on the account view Command Bar, but we can set our business logic to be run on the status change event. Let us therefore build a new “Stop account merge” real-time workflow rule with the following criteria:

We’re actually performing this after the deactivation has already taken place, but that doesn’t matter, because we’ll still be able to cancel the whole operation. We’ll look for any accounts that have gone through a status change event and are now in an Inactive state. If the account record has an account number, we’ll stop the workflow with status of Canceled and provide a message to the user explaining what are the proper steps to take in getting everything updated correctly both in the CRM and ERP systems.

Let’s try this first on a single account record. When we click on the Deactivate button on the account form’s Command Bar, the Business Process Error dialog is presented to us, along with the message we defined in the workflow. No deactivation can take place, so the account is returned back to active status. More precisely, the account record status never changes, as can be verified from the audit history log (if enabled).

Great, now let’s move on to the Merge scenario and try to combine two active accounts with account numbers into a single account. We’ll select the accounts, click Merge, go through the Merge Records dialog, defy all the instructions given to us by the CRM key user of our organization and attempt to merge two separate ERP accounts in CRM. Once we hit the OK button for the merge to be performed, the Business Process Error dialog jumps to the rescue and stops the operation.

Hey, wait a second, why’s the text in the Business Process Error window different now? “ISV code aborted the operation”, what does that mean? Well, it seems that because we’re not actually performing the status change action directly on the record but rather leverage the built-in Merge Records dialog and its associated business logic for record deactivation, our status message text doesn’t reach that screen. The event itself does “bubble up”, though, so stopping the status change also rolls back the entire transaction and none of the fields on the records being the targets of the merge operation change. That’s the important part, after all.

Complementing Business Rules

Let’s have a look at one more use case for the real-time workflow error messages before I let you get on with your browsing. The previous example covered an event that Business Rules weren’t able to control, due to the fact that they execute only on the entity form. In a CRM & ERP integration scenario you may however need to have the account record fields locked on more places than just the form. Remember that any updates the user would perform through other means, such as Excel export/re-import or a custom client app would not trigger the Business Rules that are essentially just client side scripts on the form. If you build this logic onto the server side as plug-ins or workflows, though, no one can perform an operation that would violate the rules (just ensure there’s always some supported way for performing the necessary updates & don’t block you integrations while creating these gatekeeper workflows).

One built-in form where the Business Rules don’t run is the mobile form. Utilized in both the Mobile Express browser version as well as the mobile apps for Windows Phone, iPhone and Android, these forms offer a limited set of capabilities for reading, creating and updating records. While you can set a field on the mobile forms to be read-only, you can’t build any conditional logic to determine when the field should be locked.

Let’s assume you want to allow people to quickly create and edit accounts through their mobile device, but you also want to lock down the account names on records that have been synchronized to the ERP system. To meet the first requirement you’ll need to leave the field on the form in an editable mode. To stop someone from accidentally overwriting the name of your biggest customer account with “Aasd,abhoignldfiiiiii” or other gibberish when fumbling around with CRM on their tiny little iPhone screens, you could create a real-time workflow to guard these fields from unwanted input. Have it run on the field change events, check whether it’s an ERP account with an account number and then cancel the event if necessary.

Opening up the Mobile Express UI (just append the CRM organization URL with /m/ to access this version) and trying to edit the account name field now gives the same kind of notification as the full browser client. The Business Process Error dialog window doesn’t seem to have any mobile optimized version, but again it gets the basic job done by stopping the update. I didn’t test this on the Dynamics CRM mobile apps, but seeing how at least on Android the app is almost identical to the Mobile Express browser version I’d imagine the experience is similar there as well.

OK, that’s the end of my experiments with real-time workflow process error messages for now. I’m sure that there will continue to be a need for more advanced solutions for controlling user data input that will involve hiding UI components through scripts or enforcing business logic through plug-ins, especially if the transaction volumes are expected to be high. The new workflow capabilities do however provide a quick way to configure custom error prompts and stop unwanted events when experimenting with the design options of your solutions and iterating your way towards the final production system.
November 2, 2013
Getting Your Head Around Dynamics CRM 2013 Processes – Part 2
In the first part of this series we looked at the two new process categories introduced in Dynamics CRM 2013: Business Process Flows and Actions. Now it’s time to dig deeper into new CRM 2013 functionality that will allow you to achieve process automation results in areas where custom code was previously required.

Business Rules: Processes In Disguise

You may have already heard about the new feature in CRM 2013 that promises to free us from writing Javascript to manipulate form fields, called Business Rules. If you’re looking to find them from under the Process Center, though, you’re in the wrong place. Business Rules are a property of the entity and you’ll see them alongside other such components like Charts and Views in the Solution explorer. From this we can already gather that it won’t be possible to move Business Rules across different CRM organizations as individual components like you can do with processes, instead they always travel with their parent entity in the solution files.

Business Rules have the nickname of Portable Business Logic (PBL), so there must be something else that makes them particularly easy to carry around then? The portability actually refers to the way in which the rules can be applied to all the different forms of the entity and also to how they will be carried over to the mobile client application (MoCA) on Windows 8 and iOS tablets. They are however form specific in the sense that you must define what the scope of the Business Rule is: either tied to a particular form of the entity or simply set to run on “all forms”.

What can you use Business Rules for from a process automation perspective? Similar to the Business Process Flow (BPF) process type, Business Rules can be used for guiding the data entry and update tasks by dynamically changing the UI presented to the user, based on the values of other fields on the form. Typically CRM entities end up having far more fields available than what a user is really expected to fill or even view in a particular stage of a business process. Whereas the Business Process Flow can only touch the Process Control shown on the top of the entity form, Business Rules can manipulate any field on the form, setting it either as visible/not visible, required/not required and disabled/enabled. They also have the ability of presenting field specific error messages if a user tries to deviate from the intended process.

Business Rules have a similar type of conditional statement setting as workflow processes do (if/then), but it is quite a lot more limited currently than the workflow editor options. For instance, you can only reference fields from the same entity you’re working on, so setting the requirement level of a contact form field based on the parent account record’s values won’t work. You are also limited to only specifying a single set of conditions that must all be true for the action to run. In order to build an “or” rule to cover multiple alternative conditions you’ll need to save your first Business Rule, then create a copy of it with Save As and have as many concurrent rules as there are options in your “or” statement.

Unlike the Business Process Flow processes that are only able to present fields from the entity, Business Rules can actually update the record as well. The “Set field value” action allows you to input either a static value, copy the value of another field (on the same record) or perform a simple +/-/* calculation with two fields. For an in-depth list of Business Rule capabilities and considerations, look no further than this excellent article by Jesper Osgaard on Understanding Portable Business Logic.

This first release of Business Rules for Dynamics CRM 2013 addresses many of the common scenarios where Javascript has previously been applied on entity forms to make them dynamically adapt to the business logic of an organization. However, there remain some frequently requested features that will still require form scripts to be developed, such as:
- Create dependent optionset fields (filtering available values based on another field)
- Set dynamic default values (“task deadline today+3 days”)
- Show/hide form components other than fields (tabs, sections, subgrids, iFrames, Quick View Forms etc.)
Based on the fact that Business Process Flows are categorized as a process record in CRM 2o13 whereas Business Rules are “only” a component of an entity, should you spend more time designing the Business Process Flow and resort to Business Rules only when you need to tweak some details on the forms? I personally don’t think that the BPF Process Control is necessarily the only right way for implementing guided processes in CRM 2013. For a transactional record with a linear process consisting of several stages with clear boundaries (the sales opportunity scenario) it is surely a natural fit, but in many situations the flexibility provided by the field level configuration of Business Rules can prove to be a more practical approach. At least ask yourself these question before committing to a BPF based design: 1) does it offer some required functionality that Business Rules could not replicate, and 2) can the process data naturally fit into the stages that the Process Control will display?

Real-Time Workflows: Plug-ins For The Analysts

For the past 10 years the Dynamics CRM workflows have been tirelessly performed their tasks behind the scenes, driven by the time slots that the asynchronous service on the CRM server has kindly allocated for them. Originally designed for executing workloads that didn’t have a need to present the results immediately to the same end user who triggered the event, they’ve since been frequently leveraged also in process automation tasks that would have performed much more smoothly with a synchronous execution (also known as “poor man’s plug-ins”). The powerful process automation capabilities presented in the workflow editor would have often been enough to meet the business logic customization requirements, had it not been for that delay in the logic’s execution that demanded the same logic to be replicated in custom code instead.

In CRM 2013 workflows have now been promoted to a 1st class citizen status by adding one tiny switch: “Run this workflow in the background [yes/no]”.

Why is this option of running workflows synchronously so important then? Well, if you’re just using your workflow to send an email notification to someone, there’s precious little difference in whether the action takes place immediately or after one minute. However, if you are updating the current record that the user is currently viewing through the entity form, the fact that you can present the changes right away opens up a whole new world of opportunities for leveraging workflows to guide the business process.

Nowadays when the new CRM 2013 entity form design leans towards a dashboard style of summary views presenting a number of subgrids of child entities, activities or activity feed posts, the need for immediate feedback on the UI applies also to the creation of related records through workflows. If your business process relies on the assignment of tasks to users rather than the “mark completed” checkbox driven style introduced by the new Business Process Flows, the fact that the user will see the process automation in action as he updates the records in CRM will surely help to build confidence in the system’s ability to manage the business process and distribute information to all relevant parties, without the need for manual emails or phone calls to coordinate the work.

From a development perspective, Real-Time Workflows have a similar but likely far more significant impact on the division of labor between the business analyst and the .NET developer than the new CRM 2013 Action processes that we covered in part 1. Synchronous workflow processes can cover many of the common CRM customization scenarios that would have previously required developing a plug-in. While a custom plug-in will naturally still remain far more flexible in terms of its ability to query and manipulate data, the Real-Time Workflows will drive more and more custom code to be developed as Custom Workflow Activities rather than plug-ins.

This is because of the fact that if you can isolate your code into a component that the business analyst can call from a standard workflow process, the configurability of the business process automation functionality will be greatly enhanced as future adjustments to the process can be performed through the CRM UI without touching any code. The development of re-usable components that extend the default capabilities of workflows also lowers the barrier of applying the same custom logic into new processes as the needs of the customer organization evolve.

The less people it takes to solve a business problem through CRM and the shorter the lead time from identifying the problem to deploying the solution is, the more likely it is for the problem to get solved. This is the main reason why increasing the share of configuration tasks over development tasks is so critical for any business information system that needs to adapt to changing business processes and not just fulfill a static set of requirements. If you’ve worked with CRM systems beyond their initial implementation projects, you’ll surely know into which category these systems fall into.

The Growing Business Process Automation Toolkit

If we compare the old and the new world of process automation in Dynamics CRM, we can see that the tools available for no-code configuration of business process management functionality have grown considerably over the past few years:
- CRM 4.0: workflows
- CRM 2011: workflows, dialogs
- CRM 2013: asynchronous workflows, real-time workflows, dialogs, business process flows, business rules, actions
What this means from a system administrator, customizer or business analyst perspective is that if you haven’t yet started to take advantage of the process automation capabilities of Dynamics CRM, you’re really missing out on a significant share of the platform’s potential value to your business. At the same time the growing number of options in CRM can make it seem like an increasingly difficult topic to approach. How do you know which one of the six tools to pick for building a solution to a business problem you’ve identified?

As discussed in part 1 of this article, Business Process Flows are essentially just a map of the process that you present to the end user, but they don’t perform any actions on the data on their own. Since the Action processes are currently only valid for scenarios that involve a developer resource, we can also leave those our when exploring the right tools of how to get started with CRM process automation. That leaves us with four tools to evaluate for their fit to get the job done. I’ve compiled some of the main characteristics of each of them into the following table to help you in the selection process:

You should pay attention to the following constraints of each tool when analyzing their fit for the task at hand:
- Business Rules are the only way to perform actions right after the user updates a field. Workflows will not fire until the save event (which can be 30 seconds away in the new auto-save CRM 2013 organizations).
- Workflows will run even when the records are created or updated through other means than the form (data import, integrated systems). Business Rules are only executed on the form.
- Due to the aforementioned limitation, Business Rules also only ever apply to a single record at a time.
- Workflows can reference data from related entities for read/update. Business Rules can only work with data available directly on the form.
- The special capability of Business Rules includes manipulating the UI (hide/show fields, set requirement level, show alerts). Workflows only deal with the data.
- Dialogs are a manually initiated subset of workflow functionality with a specific Wizard style UI. They also have one special skill: querying data from any entity, not just the directly related ones.
I hope that this article has managed to highlight the new features in Microsoft Dynamics CRM 2013 that can help you build solutions for guiding the user through a business process and automate the related tasks. There is a lot to explore in the latest CRM release in this area and I’m sure we’ll discover many creative ways for applying these new tools in practice as more and more customers move onto the CRM 2013 / Fall ’13 platform.
October 29, 2013
Getting Your Head Around Dynamics CRM 2013 Processes – Part 1
Workflows have always been a central part of the Dynamics CRM product. The typical need for having workflow functionality available in a CRM application has revolved around the sales force automation (SFA) requirements of implementing a sales process with predefined activities to be completed in different stages. As the Dynamics CRM product has evolved and expanded over the years (see this article for the complete timeline of MS CRM history if you’re interested), new capabilities have been added into the workflow engine, expanding the realm of possible use cases where workflows can act as the tool for automating data entry tasks, notifying users of important events or enforcing custom business logic in the various processes that CRM has been put in place to manage in customer organizations.

Initially workflows were purely background processes not intended to be visible to the end users, but in CRM 2011 a new feature called Dialogs was introduced. This enhancement gave us the possibility of building “interactive workflows” with a user interface for both presenting output as well as collecting input from the user. As a result, the terminology in Dynamics CRM was adjusted slightly in the 2011 release, with the new Process concept being used to cover the two subcategories of Workflow Processes and Dialog Processes.

The latest CRM 2013 release takes things even further on the process automation front and introduces several new features that greatly expand the platform capabilities. We’re increasingly moving away from the separation between interactive data entry forms and asynchronous background processes, towards a new reality where the core CRM product offers configuration tools for building applications that adapt to the actions of the users in real time and guide them through the business processes interactively.

Due to this expansion in functionality, the concept of a “Process” in Dynamics CRM has gotten a bit more complex than what it used to be, since a process can nowadays mean so many things. Looking at the Process Center in CRM 2013, when you click the “New” button you’ll now be presented with a selection of 4 different process categories: Action, Business Process Flow, Dialog, Workflow.

While this categorization may be perfectly valid from the platform’s perspective, I’d don’t think this is actually the most logical way to approach the available process automation capabilities of Dynamics CRM 2013. The UI presentation of the process categories ends up grouping together functionalities that are conceptually quite far apart and also leaves out some notable new possibilities that should be considered when building solutions for Dynamics CRM 2013.

In this series of posts I will try to describe how I see the current process management toolkit of Dynamics CRM and provide some guidance on which particular tool to pick up in various customization scenarios. I’ll start off by covering the two new process categories of Business Process Flows and Actions.

Business Process Flows: The Visual Process Map

The one feature that immediately stands out when launching a CRM 2013 environment and navigating to a transactional record like a sales opportunity or a service case is the new Process Control shown on top of the entity forms. This graphical representation of the business process related to the record in question is an awesome way to visualize the stages of a linear process to the end user and it will surely be the single most important feature to increase the utilization of Dynamics CRM 2013 business process automation capabilities in customer environments.

What’s really important to keep in mind, though, is that the Business Process Flow (BPF) process doesn’t provide any process automation functionality in itself. It only allows you to define the stages of the process and the fields to be populated during the stage, but the BPF won’t perform any actions on its own based on the user’s inputs. You can specify that certain fields in a stage are mandatory before the process can move onto the next stage, but you can’t enforce any other consequences. For this you will need the help of other process automation tools in CRM 2013.

Another key consideration for Business Process Flows is that moving between process stages is something the user needs to perform manually. There is nothing in the BPF editor that would allow you set conditional logic like “when fields A, B and C are filled, move the record to Stage 2 of the process”. You can leverage the Dynamics CRM platform for building such automated stage changes, but you’ll need a bit of custom code to achieve it. Refer to this blog post by CRM MVP Scott Durow for more details on how to programmatically manipulate the process and process stage fields.

Business Process Flows are essentially the way how you map out your processes to be presented to the end user. On the customization side they bare more resemblance to the entity form designer rather than the traditional workflow process editor, since you’re mainly configuring what fields to present in which stage, rather than building conditions or defining automatic actions that should take place when the conditions are met. In most scenarios you will find yourself leveraging BPF’s alongside other process types to bring in the automation part of process management.

Actions: Components of Custom Processes

While BPF’s are highly a highly visual component and therefore easy to grasp, the new Actions introduced by CRM 2013 will surely be competing for the most difficult feature for a system customizer to understand in terms of how and when to leverage them. Simply creating a new Action process in CRM won’t give you too many clues on how they are different from the traditional processes and after saving the process you’re left wondering how exactly you would trigger the Action.

In my mind the new CRM 2013 Actions bear a resemblance to a business logic extensibility feature that has been with us since CRM 4.0: Custom Workflow Activities. Rather than being a replacement, Actions are more like the other side of the same coin. Let’s compare the two:
- Custom Workflow Activities can’t be built within CRM but you can leverage them inside a workflow process through the graphical process editor UI.
- Actions are exactly the opposite: you can build them within the CRM process editor but you can’t use them anywhere without custom code.
What this means in practice that in a simple no-code CRM environment the Actions process category won’t be a relevant feature for the system customizer (at least in their current form). In a more complex environment they can provide a new practical method of keeping the organization’s business process logic outside the custom code that is being developed for UI customization and integrations with external applications.

Thinking of a real world scenario for Custom Workflow Activities, if a business analyst is using Dynamics CRM workflow processes to automate a service case SLA management process and wants to configure notifications based on the number of business days that a case record has been open, he won’t be able to achieve this with the built-in workflow date calculation tools. However, he can request a .NET developer to write a Custom Workflow Activity that will perform the required date calculation and then include this as a component in his workflow process. This will allow the actual business logic around SLA management to remain configurable in the workflow process, which means any future changes to how the case record needs to be updated, which person is notified of SLA violations etc. can all be implemented without touching the custom code that’s used only for calculating the number of business days between two dates. Also, since the custom code is isolated inside a Custom Workflow Activity, it can be referenced in any number of workflow processes.

Looking at this scenario from the Actions perspective, let’s say that we have integrated the Dynamics CRM case records into a portal or other custom application that consumes and updates the data in a similar way as the native CRM web client does. All of the entity metadata will be already be available through CRM web services, but with the help of Actions in CRM 2013 we can also expose a piece of our custom business logic to the integrated applications and manage it in one place through the CRM UI. The example that Microsoft has used while explaining Actions is service case escalation, in which the business analyst could configure all of the steps included in the escalation event (activities, case routing, service contract updates etc.) through a single “Escalate” process and the other applications could then call this message defined inside the Action. Input and output parameters can be defined for Actions to allow them to reference the correct CRM records and also provide CRM data back to the original caller.

As we can see from this scenario, just like the Business Process Flows, Actions alone won’t perform any automated tasks inside CRM. They can be used as components in defining automated tasks that are triggered based on an event that came from somewhere else, through the CRM web service. If you’d like to see how Actions might be called from a custom button in CRM through Javascript, have a look at Gareth Tucker’s great blog post on this topic.

The Real Process Automation Tools in CRM 2013

Now that we’ve gotten the two new process categories of Business Process Flow and Actions covered, it’s time for my favorite new features in CRM 2013: Business Rules and Real-Time Workflows. Even though Business Rules aren’t formally categorized as processes in CRM, and Real-Time Workflows are presented as just an extension of the existing workflow processes, in practice these are the features that deliver exactly what a CRM end user would consider as “process automation”, due to the immediate feedback that they can provide.

In the next part of this post I will explore how these new tools compare to the existing Workflow & Dialog features and how they can be combined to deliver a configurable process automation experience that goes beyond what the previous versions of Dynamics CRM had to offer.
October 26, 2013
Using the updated Activity Feeds to monitor Queues

As a part of the CRM Online Polaris update and the on-premise Update Rollup 12, new functionality has been added to the Activity Feeds solution. In fact, it’s no longer a separate solution but rather converted into a part of the Default Solution during the upgrade to Polaris / UR12 (see this YouTube video for details). Yeah, I know you were thinking that Activity Feeds are on their way out as the Yammer integration arrives, but the reality is that the auto posts functionality will still remain a CRM platform component, although the data itself may be presented through the common Yammer UI.

We’ll see how it goes in practice once the Yammer integration arrives in February (hopefully for on-prem, too, although no official info on that yet), but we’re already free to explore the enhancements of the updated Activity Feeds. In addition to the great new feature of being able to filter the records from where posts are shown in your feed instead of having to go and follow each and every interesting record, there’s also another important addition: the support for organization owned entities. Previously you couldn’t add the Record Wall onto entities like competitor but now such limitations have been lifted.

Another interesting entity that could well benefit from the Activity Feeds style of presenting the latest updates is the queue entity. Although queues themselves are a useful feature for process automation and routing tasks between users, their usability in the out-of-the-box configuration of Dynamics CRM is fairly poor. Unless you’re a full time service rep working on queues, it’s not a very intuitive way for monitoring work to be done and who’s working on what, let alone getting notified of something added into a queue that you should do something about.

Enter Activity Feeds. With the ability of having the actions in queue item updates being reflected in a timeline that allows people to also comment on the progress of these items, all of a sudden the whole queue concept can become a lot more accessible to casual CRM users. Following the relevant queues you want to receive updates from is as easy as following your teams’ accounts, and with the new filters in Polaris/UR12 update there’s even more possibilities for creating views of only specific types of queue items.

There are no standard post configuration rules available for the queue or queue item entity, so you’ll have to build the auto post rules by using workflow processes. Although the users will prefer to follow queues and not queue items, what you as a system administrator or customizer will want to do is create workflow rules for queue items and reference the related queue as a regarding object. This will allow users to see Activity Feed posts when new items are added into queues they are following, when their “worked by” information changes etc.

With the new social dashboards introduced in Polaris, it’s ever more likely that users will encounter the What’s New section when logging into CRM. Why not make the most of this and configure a few new rules for creating auto posts that surface relevant and interesting information to the users on what’s happening with the various processes that Dynamics CRM is used for managing?

January 31, 2013
Creating recurring goals with some workflow magic

Goal management is one of those features in Microsoft Dynamics CRM 2011 that has a relatively high barrier for utilization. The initial thought of measuring the business results of your organization through a built-in mechanism in your CRM system resonates with almost any customer that you tell about goal management, yet the excitement tends to wear out quickly once they discover the effort required in configuring and maintaining the goals. Sure, if you’ve only got a small organization and set goals on annual or quarterly level, it’s not such a big burden to key in the goal records with metrics and targets. But what if you’d like to measure something on a more real-time basis, like monthly or weekly? Even daily? Not such a fun thought anymore, now is it?

There are creative workarounds available for generating goals for a larger number of data points. The most practical tip I’ve come across has involved copying goal records by creating a dialog process to streamline the steps required for reproducing existing goals. I originally read about it from a presentation by Richard Knudson on Scalable Goal Management in Dynamics CRM 2011. You can view the slides from eXtreme CRM 2011 Las Vegas in PowerPoint Online or alternatively read this blog post by PowerObjects that walks you through the dialog creation process.

A different way to define goal time periods

Sometimes what you need in terms of process measurement isn’t down to the detailed level of setting individual target values for each week or each user. Maybe you have a steady weekly target of X records in a particular state and you’d just want to easily see how you’re currently performing against this target. Here’s were a more recent article by Richard comes in handy: Goal Criteria and Dynamic Goals. The big message here is that you’re not actually forced to use the From and To dates of a goal record to determine the measurement period. You can basically set a goal to be running for 20 years and instead limit the number of records evaluated by the goals Rollup Query through a dynamic date criteria like “last 7 days”.

Whit this little trick, setting up a dashboard that shows the current performance is super easy, no matter how short your goal time period is. The charts will update once per day based on the default roll-up recurrence frequency, so displaying the difference between the target and the actual value for metrics like leads qualified or calls made requires you to only set up the goal once per each variant (owner, status, type…) but not the different dates. Just stretch the goal period to be as long as you like and control the dates in the Rollup Query definition.

The downside of this approach is that the goal measurement is completely dynamic, meaning past values will leave no trace. Sure, you could enable audit on the goal entity to keep some form of results history, but since the audit data is not available for views, charts or even custom SQL reports (without some hacking), it’s not quite as easy as with the traditional method of creating goals for each time period separately.

Tracking historical results without manually creating goals

Another recent Dynamics CRM blog post favorite of mine comes from Yaniv Arditi. In his three part series (part 1, part 2 and part 3) Yaniv presents a model of how to implement an asynchronous batch process in Microsoft Dynamics CRM. Best of all, in his final post he provides a solution file that you can download and apply in your CRM organization.

What does the solution do then? Basically it is a way to implement a much needed but currently missing feature of Dynamics CRM: easily scheduling recurring workflows on a group of records. With this solution you can specify a batch process that runs every X days, performs a query of the required CRM records and then initiates a workflow process for each of those records found. You schedule it once, leave it running and the related process will always create a new waiting instance of itself once it stars at the defined intervals.

What’s the Fetch XML in there? It’s the Target Records Definition that determines for which records the workflow process selected in the Action Workflow lookup field will be executed. Where do you get the Fetch XML then? That’s easy: from any Advanced Find view, just by clicking the “Download Fetch XML” button on the ribbon.

To put this solution into work together with the concept of dynamic goals, I’ve got the following sample use case: track the number of active cases on a daily basis and compare it with a target value. This is an example of a status metric that’s not so simple to directly calculate from the records in CRM. To produce a figure like helpdesk queue length you would need to not only retrieve the number of cases created on any given day but also compare it with the closure dates of cases. It would be much easier if we could just take a snapshot of the currently open records on a set interval and store the information into CRM. So, why don’t we do just that?

First, let’s set up a custom entity called “Snapshot” to hold the data for us. We’ll establish relationships to both Goal and Goal Metric, then add the necessary fields for holding the types of data we want to track, in this case integer values for target and actual.

Next we need an on-demand workflow process that will create these Snapshot records for us from the goal data.

The batch process record shown previously has already been configured to perform the task we want: based on a daily schedule, retrieve all the goal records for which we want to be tracking the snapshots. All we need to do is set its Status Reason field to Scheduled, save the record and the process kicks off. The Asynchronous Batch Process Pattern solution will run every day (unless residing on a shut down virtual machine, like in my example image below), triggering the Take Goal Snapshot workflow, which in turn will create a daily snapshot of the actual and target number of active cases in the system. You can naturally visualize the history data with a chart, too. If you have different goal owners or several different goals to take snapshots of, just create the necessary views to filter the data shown.

To summarize, in this solution we use the Goal record as merely a “calculation machine” that produces the Actual Integer value we need. It also holds the data for the Target Integer, with the ability to update this figure if the targets should ever change. The scheduling is managed by the Batch Process record. It takes care of initiating the Take Goal Snapshot process for the selected Goal on a daily basis, which results in the creation of the Snapshot records you see above. All we had to do was to create each record once and we can leave this solution running for as long as we need.

I think this is quite a wonderful example of how you can mix’n match the different functionality of the Dynamics CRM platform to come up with a new feature that doesn’t exist in the product right out of the box, yet it can be implemented by using the platform components and supported extensions developed on top of it. Thanks again to both Richard and Yaniv in providing me with the building blocks for implementing the recurring goal solution.

October 25, 2012
Making use of Dynamics CRM process automation capabilities

You shouldn’t use Dynamics CRM only for storing and presenting data entered by users, otherwise you’re really missing out on much of the capabilities that a CRM system has to offer. Sure, the immediate need for a CRM system will often be establishing a single location for customer data, rather than having it spread out to hundreds of Excel sheets on everyone’s C-drives. Effectively managing information about who is doing what with which customers is a key benefit you should try to achieve with your CRM implementation project, but it’s just the start. You shouldn’t be happy with it and just stop there.

Another reason why processes are crucial especially when going for the Microsoft Dynamics flavor of CRM is that there isn’t much business logic configured into the system right out of the box. It’s in many ways a blank slate that is waiting to be filled with the business rules of your operational customer facing processes. For example, there isn’t a default sales process built into the system, but it provides you the tools to configure one. The beauty of this approach is that no one is forcing you to adapt your business to the way how the software works, but the price of it is that you’ll need to invest adequate time and resources into the configuration work.

Process automation doesn’t have to be something very complex or expensive, though. An example of an expensive route to take would be first arranging workshops with cross-functional business teams to discuss and define the business processes to be followed in high detail, then transforming those into functional specifications for the CRM system that the .NET developers will in turn use for designing, building and testing their custom code based solutions. While there’s nothing wrong with this traditional approach, it pretty much bypasses many of the strengths that Dynamics CRM has for a more rapid business application deployment.

If you have a CRM power user or a trusted CRM advisor that knows how to make the most out of Dynamics CRM workflows and dialogs, not only can you cut down the costs involved in implementing process automation. You also gain a new level of agility in being able to respond to new or changing business needs as they arise from your operational customer relationship management work. You can have the solution up and running within hours, plus you’re able to see the results in action the next day instead of next month, allowing you to quickly adjust the system to better match the reality as you discover new facts about it through experimentation.

Speed of iteration is something that can have a profound effect on success in business. Note that I’m not saying you should skip the requirements gathering and business process analysis steps completely, because that’s guaranteed to lead to failure. What you should however aim for is taking a step away from the traditional waterfall project flow and experiment with CRM’s capabilities already while in the analysis phase. Instead of an “all or nothing” attitude, meaning jumping from 0% system to a 100% system that meets each and every requirement, what if you could instead get 70% of the functionality into use in a fraction of time of what the delivery of 100% would take? Could it be that you’d actually find yourself in a better position to build that remaining 30% because of what the first 70% has already taught you?

People don’t often know what they want before they see it. Remember that “faster horses” quote from Henry Ford? You’ll likely receive much more concise and practical requirements from the users if they can see a prototype of the system in action, before you ask them to define what exactly it is that they need. Using the configurable workflow and dialog processes together with Dynamics CRM’s flexible data model customization tools allows you quickly build the first draft of the proposed process automation functionality. You’ll also identify at a very early stage what features can be implemented with the built-in tools and which would require custom code.

If you want to reduce the Time-to-Value of your CRM implementation, you really should look into the process automation tools that come with Microsoft Dynamics CRM and learn about their capabilities.

Where should I start?

The only right way to get familiar with Dynamics CRM workflow and dialog processes is to get your hands dirty by trying to build them in a real, functioning CRM system. If you don’t have a test environment available right now, just sign up for a 30 day trial account in CRM Online. (You can read more about how the new Office 365 integration affects the CRM Online provisioning process here.) You can bring in your own system’s customizations by exporting the solution files and importing them to the trial environment, which will allow you to test with scenarios related to your specific CRM data model. If you also need to have your actual CRM data available for testing instead of test records keyed in manually, read this article for one possible approach.

Building workflow and dialog processes in Dynamics CRM doesn’t require any developer skills, but it does take a bit of courage from the CRM system administrator or power user to dig into the platform functionality and business logic that the process editor surfaces. The web is full of nice blog posts on how to perform a specific action with CRM workflows, but it’s perhaps not the most convenient method to learn about the process automation concepts on a higher level. If you ask me, a better way to ensure you’re using your time efficiently while getting to know CRM workflows and dialogs is to do it the oldskool way and buy a book. No, I don’t mean you have to get a physical book made of paper to sit on a table somewhere, an eBook will do just fine, too.

Which book should you then get? I recommend this one: Building Business with CRM – Using Processes in Microsoft Dynamics CRM 2011. It really is the missing manual for workflow and dialog processes in Dynamics CRM. If you’ve ever searched the web for practical tips on “how to do X with Y in Dynamics CRM”, you may well have come across the website Richard Knudson’s Dynamics CRM Trick Bag. Richard, happens to be the author of this book, has been publishing an incredible amount of in-depth articles on topics like CRM customization, dashboards and workflows during the past few years on his website, making his blog feed required reading for anyone working with Dynamics CRM. You can also find several excerpts of the Building Business with CRM book from the website, which give a good indication of the type of content you can expect to find in the full publication.

While Microsoft does also have their own training materials for the course 80444A: “Workflow and Dialog Processes in Microsoft Dynamics CRM 2011”, I’d personally recommend you to get familiar with the process automation features of CRM through reading Richard’s book instead. The reason is that there is a wealth of gotchas when it comes to putting your newly acquired knowledge of available workflow and dialog functionality into practice. I personally found the Building Business with CRM book to be much more oriented towards helping the reader to navigate around the pitfalls, by highlighting not only what you can do with workflows & dialogs but also what you can’t. Understandably the courseware from Microsoft will need to have a more neutral tone of voice, whereas the CRMbizbook is able to talk about the real, everyday scenarios and explain how to work around some of the limitations that users will encounter sooner or later. What’s also great about the book (and Richard’s blog posts, too) is that you can really sense the level of enthusiasm the author has in explaining how to unlock the potential of the Dynamics CRM platform, which makes you want to go and build those example processes in your own CRM environment.

Back when I first got to know the new workflow engine introduced in CRM 4.0, after having spent some time with the very limited CRM 3.0 workflow rules, I initially had difficulties in understanding how to build some of the common workflows that business users expected the system to deliver, such as notifications for expiring contracts & opportunities. Richard’s previous book, Building Workflows in Microsoft Dynamics CRM 4.0 (Second Edition), helped me a great deal in learning the practical applications of workflow rules and understanding why things worked (or didn’t work) the way they do. Sure, blogs, forums & Google are great for finding answers to detailed questions you will have later on, but for learning the basic skills it may be better to just concentrate on a well written book on the topic.

Why the importance of CRM processes is on the rise

Looking further into the distance, we’ve already been given a sneak peek of what the future holds for the Dynamics CRM application. In the WPC 2012 session Microsoft Dynamics CRM – Now and in the Future (you can watch the session recording on YouTube), we saw that one central investment area in the next three releases is going to be the new Process Driven UI.

Previously the workflow and dialog processes have been accessible in the CRM user interface, but not really actively promoted to the user. Unless you have trained the CRM users to follow a certain business process that required them to click on a workflow or dialog, they probably have absolutely no idea what those menu items for “Workflows” or “Dialog Sessions” are doing in all the menus and ribbons found on pretty much any CRM entity form. That’s of course not such a big deal if you don’t currently (yet) utilize the process automation functionality, but it does make it somewhat complicated to introduce the concept to your users once you actually want to take them into use.

The Process Driven UI is going to bring these processes into the forefront, by showing stage information right at the top of the entity form. In addition to the visual presentation, the new UI will also allow users to interact with the process related fields directly from the stage indicator, to enter values that would have previously required launching a separate dialog popup window. For a more in-depth look at the UI changes, please see my post on Dynamics CRM Fall 2012 “Refresh” UI first impressions.

We don’t yet have details on all the planned functionality to be introduced in the Fall 2012, Winter 2013 and Spring 2013 releases, but one thing is for sure: the importance of process automation in Dynamics CRM is not going to decrease. On the contrary, there’s a good chance that these upcoming changes to the CRM UI will bring the process engine capabilities into the attention of a much wider audience. Instead of an optional feature, leveraging processes in common tasks like lead qualification or sales funnel management may even become “compulsory”, if the Dynamics CRM team decide to include some out-of-the-box workflows and dialogs into the future releases.

Combine these changes in the presentation layer with the upcoming enhancement of supporting custom workflow activities also in CRM Online (originally scheduled for Q2 2012 but now delayed to the Q4 2012 / Fall 2012 release) and we’re about to have a powerful process automation machine at our hands. For those not familiar with the custom workflow activities concept, you could describe these as pieces of reusable code that you can reference in the graphical CRM process designer UI. What this means is that if a CRM developer has built a custom workflow activity like “add business days to date” (example below taken from CRM Manipulation Library available on CodePlex), this functionality will be available to be used in any workflow or dialog process rules in that CRM environment, without the need for touching any code if the business logic needs to be changed later on.

Let’s say you’ve built a workflow process that sends out an order confirmation email to the customer. If you want to print out an estimated delivery date on the message, using a rule “order creation date + 5 business days”, you can’t do that with the standard workflows, but the custom workflow library mentioned above will help you to achieve the required output. “That’s nice, but we could have just as well written a plugin to store that date on the order form, right?” True, but then what happens when the business users discover that actually 5 days was optimistic and the printed value should now be “order creation date + 7 business days”? Well, someone will need to modify the plugin code and deploy a new version of the solution file where the plugin was delivered. How about then if the business discovers that actually orders from customers in region A should get a 5 day estimate and region B should see 7 days? Another round of changes to the code. With a custom workflow activity, all these changes could have been made by a CRM user with access to the workflow processes, by just modifying the business logic and parameters in the graphical user interface.

If you’re the CRM superuser in an organization, which route would you rather take: 15 minutes of configuration changes in the workflow process editor vs. 15 days spent in scheduling developer resources and planning solution deployment schedules, to achieve a trivial change like this? The time required for the latter option is of course completely dependent on the kind of environment and organization you happen to be operating in, but my point is that workflow and dialog processes can sometimes allow you to take the power into your own hands and reduce the friction involved in applying changes to your business information system to better comply with the changes that occur in real life business processes. That’s the reason why you should always analyze new functionality or change request by first asking this question: “can this be done with a workflow or dialog process?”

August 19, 2012
More rumors on Dynamics CRM browser and mobile support
While we wait for the official Release Preview Guide for the next Dynamics CRM update, let’s add some more water into the rumor mill. I came across an interesting blog post titled “What’s the status of Microsoft Dynamics CRM 2011 R8 (Update Rollup 9)” on the SyncraTec Solutions blog, which included the following piece of news:

The Safari browser is not going to work on the iPad. Instead, there will be a “specific mobile companion application” that won’t be available until post Fall 2012 Release. This (device-) specific mobile companion application will be based on html5 and work with any of Windows 8, iPad, or other tablet-type devices (e.g., Android).

So, not only will we be getting a new Refresh UI for the browser experience as well as the inevitable Metro CRM app, there’s also a third in-house CRM client in the works for mobile and tablet devices. Although the deal with making CWR Mobility’s CRM client available with Microsoft’s branding appears to be still in the works, this gives a whole new perspective on speculation for the reason why the mobile clients were delayed together with the cross-browser support. Why put the whole CRM Anywhere concept on hold just because the IE-specific scripts would have caused issues to PC and Mac users on an alternative browser? Well, seems like there’s more to the whole “companion” client story than slide below from WPC 2012 would have lead us to believe.

I’ve never been fully convinced that it’s a good idea to use a similar CRM client app both on the small smartphone screen and the 10″ screen of a typical tablet device (read: iPad). The use cases for these devices tend to vary quite a lot, at least in my personal experience. The upcoming Metro UI of Windows 8 seems to fit very well with the tablet scenarios that aim to replace traditional laptops as the devices which you take with you to the meeting rooms and other temporary workspaces. However, there are currently zero tablets out there running Windows RT (at least in the hands of end users) and a growing number of iOS and Android devices. Since Metro will make many Microsoft apps exclusive to Microsoft platforms again, how do you capture the audience that needs a mobile CRM solution but doesn’t want to replace all their hardware the very moment Win8 becomes generally available?

It appears now that this is a market Microsoft intends to go after, by building a HTML5 based client specifically designed for the smaller screens. Based on the above quote, we’ll see an app that is platform specific, but will they take the same route as Facebook did with their iPad app and just embed a browser view into the UI chrome of iOS and Android operating systems? Or will there be more native features used in each platform, which would be the opposite approach to the responsive design paradigm that’s become trendy with public websites nowadays? And what will remain as the domain of the existing iPad app that was promoted so much back in Convergence 2012?

Another question that arises from statement of “CRM on Safari browser will not work on iPad” is whether this means Dynamics CRM is not officially supported on that browser/device combo or if Microsoft will actually actively block the usage of the browser client on a tablet device? Earlier this spring the message was that the browser support matrix published would indicate which platforms would fall under Microsoft’s customer support plans, but other devices like Android might still work OK. Although the Dynamics CRM browser user interface that has been designed to be used with a mouse would surely not be optimal on a multi-touch tablet, the initial reports from running the UR9 / R8 beta on the iPad Safari browser were saying the experience wasn’t actually that bad at all.

Returning back to the R8 discussion, we now have confirmation also from a Microsoft representative that the following features will not be published this summer but instead be delayed until Q4 2012:
- Custom workflow activities on CRM Online
- Activity Feeds solution update with view filters
Bummer. Many developers and ISV’s were really waiting for the possibility to start utilizing custom code in workflow processes, but now with CRM Online still not supporting them and 2/3 of new Dynamics CRM customers choosing the Microsoft hosted cloud platform, there’s not much opportunities to release commercial solutions with custom workflow activities until later this year.

Why the Activity Feeds update is not released either is difficult to understand. While testing the R8 beta the new filter features seemed like a very welcome addition that would surely make it easier to deploy Activity Feeds into the day-to-day operations of CRM users without worrying about how to get the users to follow relevant records. The only sensible explanation for this delay could be that Microsoft has decided to pull back some of their own feed functionality and try to merge them with the Yammer platform’s capabilities. Given the relatively short time frame until Q4, I’m not sure how much integration could actually be developed between Yammer’s feeds and the MS stack of business applications, but let’s see how this thing develops.
July 31, 2012
Using hashtags in Activity Feed posts to automate processes
Improving internal collaboration has been the driving idea behind Dynamics CRM Activity Feeds. Even though the efficient usage of stream-like notifications may not be immediately obvious to users who’ve come to think of CRM data as permanent records presented in views, they provide a great enhancement on top of the existing customer data that focuses on answering the “what’s going on right now?” question, rather than the “what/who/how much” types of queries that CRM systems typically have focused on. Joel Lindstrom wrote a great article on the Customer Effective blog about how Activity Feeds are different from RSS feeds, which I recommend everyone to read.

Originally launched in the Q4 2011 Service Update (R7), the Activity Feeds solution is about to receive some enhancements in the upcoming R8 release that will allow users to better filter the content of their wall and also click “like” on posts. (Note: contrary to some comments, the “unlike” feature will most likely be simply the undo action of “like”, rather than a real “thumbs down” reaction.) Compared to other social business applications like Yammer, there still doesn’t seem to be built-in support for features such as groups or hashtags that we’ve come accustomed to use on many platforms. I’ve already written about a DIY approach for leveraging custom groups to follow posts on specific topics. Next, I thought I’d see how we could make use of the hashtag concept in Dynamics CRM.

What’s a #hashtag & what’s it good for?

Whether you’re an active Twitter user or not, it’s likely you’ve come across a person using the # sign in his or her online writing. What started out as a user driven policy of grouping tweets has later turned into a whole movement that’s gotten both users as well as commercial entities get very interested on following, measuring and encouraging the use of #hashtags on social media channels.

Twitter allows the users to click on hashtags turned into hyperlinks, thus enabling them to view all recent posts containing the same hashtag. Although Dynamics CRM is a flexible platform for LoB application development, tweaking the default Activity Feeds solution web resources to support this kind of filter functionality wouldn’t be exactly a walk in the park. However, we can certainly explore the concept and see what else the platform might have available for us that could make the Activity Feeds more intelligent. Hmm, how about workflows?

While the post box on a wall doesn’t currently allow us to include any other “magic characters” apart from the @ symbol used for performing mentions, the pound sign does have one clear advantage: it’s rarely used for other purposes than a hashtag (you might have the occasional shouts of “we are #1!” by excited sales reps appear on the wall after they close a deal, but that’s about it). This means we can quite safely use the # symbol as an identifier for our own little magic words.

Triggering processes from wall posts

Suppose you’re browsing through your personal wall on a Windows Phone 7.5 mobile while sipping on a Venti Latte at Starbucks, utilizing the free Microsoft Dynamics CRM Mobile app. You spot an item in your feed that you want to take note for further action once you’re back at your office desk. How are you going to do that?

While an email inbox is hardly a good way to manage a list of open tasks, Activity Feeds are even worse as action items, because they’re not even meant to be persistent records with read/unread status or flags/categories. The stream flows on as other CRM users perform actions such as winning opportunities and solving support incidents, which means that the item you spotted while enjoying your coffee may well be buried into the depths of history the next time you glance at your wall. Posts are merely notifications about something, not the object itself.

Instead of resorting to disconnected manual notes, what you could do is track the regarding record of the interesting wall post as a new task on your own list of CRM activities. All we need is the creation of a very simple workflow rule to achieve this. Create a new workflow process on the Post entity and mark it to be started whenever a new Post record is created.

What the hashtag concept will be used for is evaluating the content of a Post and seeing if the workflow process should be run or not. In our example, let’s use the hashtag #task to identify a Post which we would like to trigger the creation of a new task record. You might also want to check that the Post source is Manual Post instead of Auto Post (more about that later).

In your workflow rule definition, create a new task record and insert the contents of your post in the subject line. Set the regarding field to be the RegardingObjectId of the Post, owner as the person who created the Post, and a due date of 1 Day After Created On. Save your process, activate it and you’re all set.

Just type #task and let the system take care of the rest

In our example, we’ve spotted a Post regarding a new opportunity record. (Ok, so we’re doing this from the web client and not the mobile one, since believe it or not, screen capture on WP7 requires an unlocked device!) We want to mark an action item on the record for us, so we post a new item on the record wall, using the hashtag we defined: “#task Ask Chris for customer references”. Please note that simply commenting a Post will not trigger a workflow, since the PostComment entity is not available for workflows (bummer), so make sure to type a completely new Post on the item of interest.

After the Post is submitted to CRM database, the workflow is triggered and a new task will have been created on you My Activities view in a matter of seconds. Should you ignore your CRM list once you return to the office (shame on you!), the due date reminder we set on the task will cause your Outlook (and probably also your mobile phone) to alert you about the action item you created for yourself.

Drive any process with #hashtags

As you might know, the free mobile client does not allow you to create or update any CRM records, you can only read them on your mobile phone (unless you want to open the somewhat less pretty Mobile Express client). The only exception is Activity Feed Posts, which you can type on your Windows Mobile device and get the data updated into CRM in real time. Together with the creative use of hashtags and workflow processes, we can actually trigger also some other data entry and updates while on the road, as you saw from the #task example.

While you can’t create a workflow that would update the parent object of the Post, you can create new child items for it. In the example below, we’re creating a new case by using the #case hashtag.

The steps of the workflow process configuration are as follows:
- Check if the Post contains the text #case
- Create a new case record, set the title to post text, set customer as the RegardingObjectId(Post)
- Create a queue item for the new case and move it to the Support queue for CSR’s to start working on
- Wait for the case status to change from active to something else
- Create a new post on the customer wall, containing a summary of the information recorded on the case after its creation
- To finish the process with confidence on both sides, also send a direct email to the person who initiated the case creation with his/her wall post
All this process data neatly managed inside Dynamics CRM, just because you typed “#case Send an evaluation license of Product X to customer” on a record wall, with a mobile phone on your one hand and the latte on the other. You might as well have used a similar process to open a new opportunity and start your sales process automation tasks, with a predefined product specific hashtag like #opp_prodX_3m, if you really wanted to impress your colleagues that haven’t yet figured out why Activity Feeds and Auto Posts are a true productivity boost rather than just another new inbox to process.

A final word of warning: since you probably don’t want a workflow generated Post to trigger any new workflows accidentally, it’s a good idea to always set the right Post Source value (Auto Post, Manual Post) and also filter these in your workflow conditions. As an example, if you post “#case Customer asks for refund” and then later on use it as the case title that gets inserted into a new Post, you’ll soon be stuck in a loop of each case resolution creating a new case…
February 23, 2012
Storified: Microsoft Dynamics CRM R8 and beyond

February 9, 2012