Jukka Niiranen

Tag: process

  • 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.

  • 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?”

  • Dynamics CRM Fall 2012 “Refresh” UI first impressions

    Last year the Microsoft Word Partner Conference gave us a first look at the Activity Feeds solution and other R7 feature enhancements. This year in WPC 2012 we got a taste of things to come in Dynamics CRM on not just one but two client UI’s. Although the Metro CRM app is surely a more significant step in the long run, the updated browser UI will initially have an impact on a much wider user base. That’s why I decided to blog about these news first before jumping into the world of Windows 8.

    The screenshots in this post are taken from the recording of the WPC session titled Microsoft Dynamics CRM — Now and in the Future, in which Bill Patterson presented the future roadmap of Dynamics CRM. We’ll be getting an updated Release Preview Guide soon which hopefully goes into more detail about the changes and new features, so consider this just a sneak peak into what’s coming in the next Dynamics CRM update.

    After the R8 / Q2 2012 release contents on the browser front were rescheduled, we’ll now be getting visible changes also on the Internet Explorer user experience in the Fall 2012 release (in practice the Q4 2012 Service Update). The new “Refresh” UI will take the classic browser experience closer to the Metro look & feel, but it is not the same thing as the Metro app. Point & click mouse interaction is still the focus here, although with cross-browser support you will at least theoretically be able to run this on a tablet with a touch UI.

    The changes in the main screen of Dynamics CRM browser client do not appear to be functionally significant, rather just small tweaks in the colors, fonts and other details. We’re moving from the Vista style Aero UI into a simplified, flat Metro UI, which will be visible in all Microsoft products very shortly.

    The entity form windows will experience a much more significant update. Please note that one of the focus areas in the Dynamics CRM roadmap for Fall 2012 is developing the application functionality specifically for opportunity and case management, so I expect these changes will not initially impact all the entities. The demo at WPC covered lead and opportunity forms, below is a screenshot of how the lead form appears in the “Refresh” UI:

    Wow! We’ve come a long way from the CRM 2011 UI. Where should we start with going through the changes?

    Let’s take the ribbon first, or more specifically the lack of it. Although the main window of CRM will still present the full application ribbon, at least on the lead & opportunity forms the ribbon will be minimized by default. Clicking the “More” button will presumably reveal the ribbon, but we didn’t see this in the demo, because the intention of Microsoft is to hide it away as much as possible.

    “Hey, didn’t we just get the ribbon 1.5 years ago?” Yes, we did, but it doesn’t fit with the Metro design principles anymore, which state: only deliver the right information to the user at the right time, don’t overwhelm them. Touch UI on tablets and phones makes this even more important, which is quite easy to understand. For the power users (most of the readers of this blog, I’d imagine), the wealth of functionality presented on the ribbon must have felt like a welcome addition back in Office 2007 or CRM 2011, but this doesn’t necessarily mean it’s the right design choice for a CRM application. Results of the usability research Microsoft has conducted can be summarized in the following quote from Patterson:

    “Ribbon is great for the power user, but the everyday user just wants the file menu back.”

    Well, that’s it then. RIP ribbon 2011-2012, it was nice to know you. While the reality may not be quite as black & white, anyone designing solutions on top of the XRM platform should definitely take the inevitable fate of the ribbon into consideration.

    If we don’t have the ribbon there to guide the user anymore, then what can we use instead? The answer is: processes. What is called the Process Driven UI in the development roadmap will in practice manifest itself as a graphical, interactive process stage indicator on the top section of the entity form.

    According to Patterson, the new UI is built on the Dialog Process foundation established in the original CRM 2011 release. Presumably the arrow titles will then come from process stage names. Each stage can contain multiple steps that the user needs to complete (although they don’t appear to be mandatory, at least in the lead qualification demo). Logically these would then be created with the Prompt and Response pairs available in current dialogs. The user can progress from one stage to another manually by clicking arrows on the far right corner of the process graph, but presumably there will also be support for creating conditions for automatic rules to update the stage of a record.

    Without knowing much about the features and initial limitations yet, the Process Driven UI looks like an excellent addition to the Dynamics CRM application. Workflow and dialog processes have so far been almost invisible to the user, which has made CRM look like just a static place for entering, reading and updating fields on a form. By bringing the process thinking into the foreground, the barrier for using CRM to really automate business processes will become significantly lower, which in turn can make the application a much more valuable tool for the organization using it.

    Moving on with the UI review, into the main form sections, we can see another welcome addition: the built-in follow-up activity functionality is back! When the form assistant was deprecated in CRM 2011 we lost the ability to quickly create follow-up actions from the previous activity form (unless you built a custom process for this, as I’m sure many organizations have), but now it returns into the  core Dynamics CRM application.

    These follow-ups, like any other related record presented on the form, are fully editable directly on the parent entity form instead of a separate pop-up window, which has been a paint point that Microsoft is working hard on trying to eliminate. Modern web apps don’t have popups and modern devices (tablets and smartphones) don’t support them, so inline editing is the only sensible way going forward.

    Notice how the traditional form fields of a lead are all stacked up on the left side. With the related entities navigation collapsed by default, this single column approach actually looks pretty good. Must be because the iPad and Metro apps are teaching us that fields don’t exist side by side but on top of each other. But what do you then fill the rest of the screen with?

    The answer: related records. In the opportunity form example there are subgrids of stakeholders (Connections), Competitors and pursuit team (possibly new team management related entity, or just a Connection type?), although they barely look like subgrids at all since the Metro style form design blends these seamlessly into the entity form. In the middle there’s a combined list that shows Activity Feed Posts, Activities or Notes, depending on the selected tab. Another design choice that sure feels better than spreading these records into a wall web resource, subgrid and a notes/attachments list as they are in the current CRM 2011 UI.

    Also pay attention to the top right corner of the form, where there is a highlighted section of entity fields, in this case the opportunity probability, rating, estimated close date and estimated revenue. Whether these are business required or business recommended fields that get automatically promoted into this section of the UI remains to be seen. It’s like a form header section that is actually editable, which could be another possible implementation method. As you may or may not have noticed yet, the header and footer section of the lead and opportunity forms are now history, with no apparent way of bringing them back, unlike the ribbon with the “More” menu.

    All in all, what the WPC 2012 demo showed us is almost like a whole new application. The way in which the lead-to-opportunity process now flows within the same window, without a single pop-up window is nothing short of revolutionary, if you compare it to the current Dynamics CRM UI logic. The navigation paths in the application have remained fairly static from v3.0 to 2011, with the latest major version adding a large amount of new UI components (ribbons, charts, subgrids, filters) into the mixture but not really changing the core concepts. Now with the Fall 2012 browser client update and the Metro CRM app looming in the horizon, all of a sudden the  Dynamics CRM user experience is about to get redesigned in a major way.