Tag: usability

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

    CRM_2013_Process_Center

    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.

    CRM_2013_Business_Process_Flow

    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.

    CRM_2013_Business_Process_Flow_2

    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.

    CRM_2013_Action

    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.

  • CRM Rocks Podcast: Discussing the New CRM 2013 Features and User Experience

    CRM_rocks_podcastThere’s a large number of great CRM blogs out there, but how many Dynamics CRM podcasts do you know of? Well, here’s one website you should definitely take a look at: CRM Rocks! Markus Erlandsson has started a new podcast series that focuses purely on Microsoft Dynamics CRM topics.

    In the first episode Markus interviewed CRM MVP Gustaf Westerlund on the available tools and best  practices that any Dynamics CRM developer should be aware of. I had the honor of being guest nr. 2 on CRM Rocks and got to share my thoughts and observations on the latest and so far the greatest release, CRM 2013. Click here to access the podcast recording in MP3 format.

    Some of the topics that Markus and me discuss during the podcast include:

    • The new UI: how will the new form design impact the user experience and what requirements does it impose on system customizers.
    • Business Process Flows: how are they different from the other process types and what do they mean in practice for the management of tasks related to business processes such as sales opportunity management.
    • Business Rules and Actions: what are the new options for code-free CRM configuration and where do we still need .NET developer resources.
    • No more ribbon: are we missing out on past functionality or are we actually better off in the end.
    • A world without popup windows: why is CRM now easier to learn for new users.
    • One CRM platform, many CRM applications: what the extended client support for mobile devices means for CRM usage scenarios.
    • Auto save = no more “post buttons”: why you need to be careful when upgrading your custom business logic stored in scripts and plugins.

    I personally enjoyed the discussion a lot and if anyone has 55 minutes to spare on listening to my ramblings on CRM 2013 then I hope you manage to get something out of it, too!

  • Your Essential Toolkit for Microsoft Dynamics CRM

    You can do a lot with the configuration and customization toolkit that Microsoft Dynamics CRM offers. With the SDK and some lines of custom code, you can do almost anything. There in between lies the territory where the Dynamics CRM community is helping its members manage some of the commonly required tasks without the need for .NET developer resources. This is done through a wealth of wonderful, free tools that make it easier for anyone working with Dynamics CRM to access the power of the platform without getting their hands dirty in tweaking XML files or learning the right SDK calls.

    Many of the tools listed here are a permanent fixture I take along with me to any consulting gig, while some are new entrants to the list. If you’ve been actively reading up the posts on various popular CRM blogs, you may well recognize most of them. However, while I personally spend far too much time on social media channels, I realize that not everyone in the industry has the luxury for such a lifestyle and may have therefore missed out on some tools that could have saved them hours worth of work. Therefore, I decided to compile a “Best Of” post to highlight the 10 tools no CRM consultant should be without. (For anyone wanting to stay on top of the latest tools and solutions I come across, you can either subscribe to my Dynamics CRM Links RSS feed or follow the Surviving CRM page on Google+.)

    CRM 2011 User Settings Utility

    Download from CodePlex.

    When setting up new user accounts in your Dynamics CRM organization, wouldn’t it be nice if the system administrator could set their personal settings to match the policies of the organization as well as the likely preferences of the user in question? Things like Time Zone, Records per Page, Advanced Find mode, default home page etc. can be easily configured for users in bulk with the CRM 2011 User Settings Utility by Amreek Singh.

    CRM2011_User_Settings_Utility

    One particular pet peeve of mine related to the default configuration of Dynamics CRM is that new contact records are automatically created from tracked email sender or recipient addresses not found in the database. Well, with this tool you can stop the users from unintentionally populating your database with partially filled contact records not associated to their proper parent accounts by simply configuring the setting to “No” for all users. Beats having to send everyone instructions by email on how to check their CRM profile settings, doesn’t it?

    Universal Settings

    Download from Sonoma Partners website.

    It’s not only the user settings that may require you to pop the hood open on your CRM instance. There is a number of Organization Settings as well as Deployment Settings that can be used to either overcome limitations or alter the default behavior of Dynamics CRM. For example, if you’d like to be able to export all of your contacts records from CRM to Excel and not just the first 10,000 then you’ll be happy to know that changing the MaxRecordsForExportToExcel parameter is a breeze with Universal Settings, no matter if you have an on-premises or CRM Online environment.

    UniversalSettings

    Another handy limit you can adjust with the tool is AggregateQueryRecordLimit, which will allow your charts to summarize more than 50,000 records at a time, instead of seeing “the maximum record limit is exceeded” errors. Also very handy if you wish to work with more than 50,000 marketing list members in your campaign target group. Unfortunately this tweak is not available for CRM Online, though, as the setting resides in the deployment table rather than the organization table, which is the only one you can update in the cloud.

    XrmToolbox

    Download from CodePlex.

    We’re now stepping into the world of “Mr. CRM Tools” himself, a.k.a. Tanguy Touzard. His awesome Toolbox for Dynamics CRM 2011 is a collection of the various tools developed over the years to help make Dynamics CRM administration and customization more efficient and enjoyable. By downloading the Toolbox you’ll get a number of great tools, but just to ensure you understand why you need them, let me give a quick intro to my favorite ones.

    Sitemap editor

    Adjusting the CRM main page navigation (a.k.a. sitemap) is something that you should always perform after you’ve determined what are the entities your different user groups (sales, marketing, etc.) will need to access and what is the logical arrangement of them in the navigation. Trust me, the right answer is not “the order in which the entities were created” nor “alphabetical”. There’s a number of free sitemap editor tools out there, but since XrmToolbox is such a powerhouse, it makes a lot of sense to use the the same tool that you’ll be using for other tasks in the same organization, as you’ll only need to configure the connection parameters once.

    Sitemap_editor

    Re-arrange, add, hide, group, rename, do basically whatever you want with the CRM menus with this editor without ever seeing a trace of the solution XML file contents.

    Easy Translator

    Easy_translatorThe latest addition to XrmToolbox is something every CRM admin from a non-English speaking country can surely appreciate. Since most of us still prefer to use the English base language setting in Dynamics CRM due to the awkward terminology of our native language translations in the customization UI (and any potential technical compatibility quirks that come with it), working with the “export/import labels for translation” process is all too familiar to us. Hunting down those strings in the unstructured output file isn’t very pleasant, which is where Easy Translator comes in handy. You’ll get a nicely arranged Excel with just the types of labels you’ve selected for export, which reduces the amount of trial & error in translating fields, values and form labels to the language of your choice. (more…)

  • No-code Customizations with North52 Formula Manager, Part 3: Case Resolutions

    In the previous articles (part 1 and part 2) we’ve explored how the North52 Formula Manager can be utilized in automating steps related to the sales process. This time we’ll be looking at a scenario related to service management, in an effort to make it easier to share knowledge and report on the resolutions of cases recorded in the Microsoft Dynamics CRM database.

    Cases vs. Case Resolutions

    Case_resolve_cancelIn theory it should be pretty straightforward how you work with a case record: they are support tickets that are initially open (active) when you create them and eventually they end up getting closed as either resolved (service was provided) or cancelled (duplicate ticket, customer never replied etc.).

    The point where complexity raises its ugly head is how the resolution process works: instead of entering the case resolution details onto the case record itself, the user is presented with a window that creates a Case Resolution activity underneath the parent case. While this is a perfectly valid design in terms of the nature of the interactions, as there could be situations where the case gets re-opened and resolved again (thus being a 1:N relationship with the case), it does make it more complicated to work with the resolution data later on.

    Resolve_case_dialog

    For example, say you’d want to study the resolved cases by using a view of the case records. In that view you can see the case subject, owner, status and other standard fields, but there’s no information visible on what the actual resolution to the case was. “Ok, so I’ll need to customize the view and show columns from a related record. That’s not too difficult, now is it?” Unfortunately that’s not going to work, because the information we’re interested in resides on the N side of the relationship. Since there can be several case resolutions for a single case, no columns from this entity can be displayed in a case view. So, we can’t construct a nice Q&A list that the service reps could leverage in scanning for similar cases on a new question from a customer. We can only see the problem, not the resolution.

    Resolved_cases_view

    You could build a view of case resolutions, the child entity in this relationship, but that’s not very convenient either. Although case resolution is an entity of its own, it’s not actually available in Advanced Find to directly build queries on. It is possible to access a list of case resolutions by crafting a view of activities with that specific type, but you’ll still be limited to only the generic activity fields. As an example, the field Billable Time (Time Spent) cannot be accessed in a view, which makes it rather difficult to report on this data entered as a part of the service process.

    Activities_Advanced_Find_case_resolution

    Using a Formula to Replicate the Case Resolution Fields on the Case Form

    Luckily Dynamics CRM is a flexible platform that allows you to develop new business logic to fulfill the requirements for your service process. In this situation, if we could simply have the Resolve Case dialog fields copied over to the parent case, this would solve the aforementioned problems. So, how to proceed then?

    If we want to alter the default behavior or the service entities, we should first have a look at the workflow process capabilities of Dynamics CRM to see if can  configure a workflow rule that is triggered when the case resolution is created. This time we won’t get very far with that idea, though, as neither the case resolution nor the activity entity can be used as a workflow trigger. Fair enough, we’ll then need to come up with a lower level solution to meet this requirement. Assuming we have access to a .NET developer who knows the Dynamics CRM SDK, creating a custom plug-in to copy the fields to the case record would be a worthy option to consider. Since the title of this post promised “no-code customizations”, let’s instead look at how we could achieve the same functionality with the Formula Manager.

    First we need a place to host the case resolution data of course, so let’s add three custom fields on the case entity: Resolution (text field), Resolution Description (multiple lines) and Time Spent (whole number with duration format). On the case form they can be put into a section of their own and set as disabled, since the user shouldn’t directly update them.  Then we’ll create the three formulas that will populate these fields with corresponding values from the case resolution entity.

    Case_custom_fields

    We’ll be using a formula of the type “Save – To Parent” and attach it to the create event of the case resolution entity. As our target (parent) entity we can select case, but notice that you’ll actually need to specify the relationship field value first before you’re able switch the value in the target entity field. Let’s take the Resolution Description field we just created as the target property. The formula itself in this case will be very simple, since all we need is a value directly from the source entity. We can use the source entity tree visible in the bottom left corner of the screen to browse through the available fields or just type in directly the value [incidentresolution.description].

    Formula_case_description

    The other two fields will get an identical treatment, which means we can click on the Clone Formula button on the ribbon and create two copies of the original formula. Just update the target property field and select a new source field value into the formula description window accordingly. After we’re done, we can publish the formulas and try them out by resolving an existing case.

    Resolve_case_formula_1

    After we’ve entered the details into the Resolve Case dialog fields and clicked OK, our formula will update the underlying case form in real time to reflect the same values presented directly on the resolved case record. Unlike asynchronous workflow processes, the formulas can perform their tasks right in front of the user, which makes the user experience more consistent.

    Resolve_case_formula_2

    Making Use of the Resolution Data

    Now that the fields are available on the case entity, we still need to ensure that the user actually has access to them through all the necessary routes. First we should of course include them into the Resolved Cases view we talked about earlier.

    Resolved_cases_view_updated

    Seeing the resolution field contents directly in the view is a great improvement, but an even more important feature is to enable the users to search for this information. You see, one of the peculiar default settings of Dynamics CRM is that the Quick Find view for case entities only covers active (open) cases. (more…)

  • No-code Customizations with North52 Formula Manager, Part 2: Line Items

    In a previous post I wrote about how the North52 Formula Manager solution can help you build some common customizations that would otherwise require writing Javascript for Dynamics CRM entity forms. The scenarios included:

    • Setting default values for lookup fields
    • Dynamically changing the field requirement level
    • Displaying popup warnings
    • Launching dialog process windows

    This time I will show a few examples of the Formula Manager capabilities that would typically fall into the domain of writing C# plugin code to enhance the business logic of Dynamics CRM. Being a functional CRM consultant that doesn’t normally deliver a single line of code (at least for production environments), these scenarios would traditionally require me to hand over the task to a CRM developer. What we’re about to see is an alternative method of creating just formulas with the graphical tools available in the solution package to get the same job done.

    Updating Opportunity, Quote, Order or Invoice Products

    In Microsoft Dynamics CRM 2011 you can trigger workflow processes on the line items of Opportunities, Quotes, Orders or Invoices. This allows you to execute custom logic when, for example, new Quote Product rows are added for a Quote record. Unfortunately what you cannot do with standard workflows is to actually update the line item record itself.

    Workflow_update_quote_product

    Well, this surely looks like a dead-end for most of the use cases you could think of for triggering the workflow process in the first place. If I wanted to, for example, pull information from the selected Product record and save it on the Quote Product’s fields, such as product description, vendor details or a line item number to sort the quote rows, this apparently cannot be achieved with CRM’s workflow functionality.

    Let’s look at how we can solve the problem with Formula Manager instead. In our scenario we would like the description field of the Quote Product record to be updated with the description field contents of the selected Product record. What we therefore need is a “Save – To Current Record” type of formula that is triggered on the Create & Update events of the Quote Product entity. We can limit the update events only to the Existing Product field by setting the Source Property value. The Target Property of our formula should be the Description field.

    Finally, we need the actual formula that will feed the values from the related Product record into the Quote Product’s description field. To retrieve the description field contents we’ll use the FindValue function and tell it to search for a Product record that has the same productid as the existing product selected on the Quote Product record. While we’re at it, let’s also ensure that the Quote Product actually has an existing product instead of a write-in product by verifying the productid field contents with the ContainsData function. The end result will look like this:

    if(ContainsData([quotedetail.productid]), FindValue(‘product’, ‘productid’, [quotedetail.productid], ‘description’),’NoOp’)

    FormulaManager_update_quote_product_description

    Now when we navigate onto a Quote and add a new Quote Product record underneath it, the description field will inherit the value from the related Product and display it directly on the Quote Product form (assuming you’ve made this default field visible on the form in the first place).

    Quote_product_description

    Not that much more complicated than building a workflow rule, just as long as you familiarize yourself with how the formulas work and how to format the parameters required by the functions.

    Creating Line Items

    Let’s proceed with exploring the world of line item records in the sales process. Updating existing records automatically is a nice capability to have for sure, but what about automating the complete process of creating the line items for an Opportunity, Quote, Order or Invoice? For example, if we wanted to ensure that there is always a standard Delivery Fee or other persistent item included whenever we’re creating an Order of a specific type (or for a specific customer group), then this is another area where the out-of-the-box functionality of Dynamics CRM workflows can’t be used, since new Order Product records cannot be created through a workflow rule.

    With Formula Manager we have no such limitations in place, rather we are free to create any type of records we want with the CreateRecord function. The example formula below was actually provided to me by North52’s John Grace to demonstrate the solution’s functionality. The Save – Perform Action formula is attached to the Create event of an Order record, which in turn triggers the creation of a new Order Product record. The contents of this auto-created line item can be defined either directly in the formula or alternatively queried with the FindValue function familiar to us from the previous example.

    CreateRecord(‘salesorderdetail’,
    1,
    ‘salesorderid.salesorder.’ + [salesorder.salesorderid],
    ‘productid.product.’ + FindValue(‘product’, ‘name’, ‘Bike’, ‘productid’),
    ‘uomid.uom.’ + FindValue(‘uom’, ‘name’, ‘Primary Unit’, ‘uomid’),
    ‘quantity.10’
    )

    FormulaManager_create_order_product

    Now, as a limited time special offer, any new Order that we create (or a Quote that we convert) will get 10 Bike products added onto it with their unit price dynamically retrieved from the Price List selected on the Order. What a sweet deal!

    Order_Products

    Cloning Records

    For a Dynamics CRM administrator these type of automated steps can be really handy in enforcing business rules and ensuring correct entry of data onto sales records. If we’d show them to your typical salesman, though, he might not be so impressed with this type of detailed process automation functionality.

    “Sure, it looks like we could save a few clicks with these formulas. But here’s the deal: many of the quotations I make are practically identical. They contain the same line items every time, with only some variations in quantity and discounts given. What I’d really want to do is simply select a quote I’ve created for another customer and create a copy of it. You know, the “Save As” button that’s found in all the other Office applications. Why couldn’t CRM also have that? It would be a huge time saver for me.”

    Ever had this kind of a discussion with your CRM users? If you have, then you’ll surely appreciate the fact that Formula Manager provides a Clone function that allows you to create a new copy of any existing record. Not only that, but the function also clones all the related 1:N & N:N records, which means you can create a copy of both the Quote and Quote Product line items with a single function!

    To get an understanding of how the function could be leveraged in delivering the “Save As” functionality your sales users have been asking for so long, watch this video that demonstrates not only the formula in action but also how you can use the Ribbon Workbench to build a custom Clone button for the required entities.

    Clone_Quote

    Think these type of features would be useful to have in your Dynamics CRM organization? Then go ahead and grab the fully functional Standard Edition of Formula Manager that allows you to have 10 active formulas at a time, for test or production use.

  • No-code Customizations with North52 Formula Manager

    North52North52 Formula Manager is a very interesting solution that promises to simplify the process of customizing and extending Dynamics CRM by offering a graphical toolkit to implement custom business logic that would otherwise require developing plug-ins in C# or adding Javascripts on the forms. Instead of writing custom code, the business logic can be configured through the N52 entities inside CRM, with the help of a Silverlight based editor to write formulas that check conditions, perform validations, update fields etc.

    In this article I’ll show you a few simple examples of how a person with no coding skills can perform some customizations that go beyond the GUI tools that Dynamics CRM offers. I’ll use the opportunity entity to add some client side actions to make the sales process a more guided experience for the end user. You can grab the free Standard edition of Formula Manager and use it’s 10 available formulas to try out these examples in your own CRM environment, or watch some of the training videos from North52 that cover several other scenarios.

    Default values

    The sales records in Dynamics CRM contain a few fields that sometimes don’t deliver any added value to the user, but they still need to be filled for each record. One common example is the usage of the price list. If your organization only has a single valid price list at any given time, the CRM users would surely appreciate it if the system could automatically populate the lookup field with the default price list when creating a new opportunity.

    Opportunity_default_price_list

    This is a very simple formula where all we basically need to do is populate a lookup field with a static value. To get the GUID of the price list, open it’s form in a new IE window by pressing Ctrl+N and find the string like “3F2504E0-4F89-11D3-9A0C-0305E82C3301” from it. Then create a new N52 Formula record and define the formula type as Save – To Current Record. We’ll set the mode as Client Side Classic and set it to run on the Create event, as we want the price list field to be populated with the default value only once – when the user creates a new opportunity record. The source and target entities should both be set to opportunity, as we’re updating the current record. The source property in this case is the event that triggers the formula, so let’s select OnLoad to fill the field immediately when the form is opened. Finally, the target property should be the field that will be updated with the results of the formula, in this case Price List.

    Different field types on the CRM form require different kinds of update procedures. Since we’re dealing with a lookup field and populating it as a client side event, let’s pick the SetClientSideLookup function from the N52 Formula menu and give it the required parameters of the entity name, record GUID and record display name:

    SetClientSideLookup(‘pricelevel’, ‘5EF541AA-67B6-E211-93F7-08002719F2F4’, ‘Default List’)

    FormulaManager_opportunity_default_pricelist

    Now we’ll just need to publish the formula and go test it out by creating a new opportunity record and verifying that the price list gets set to the record we wanted. In case you get an error prompt from N52 Formula Manager while opening the form, please revisit the formula record and verify that you’ve selected the correct options.

    Required fields

    Changing the requirement level of a field based on another field on the form is another common requirement. Let’s assume we have a simple sales process with three stages (picked up from the default CRM sample opportunity data): 1) Prospect, 2) Qualify, 3) Closing. We’ll use the Status Reason field’s (customized) values to drive the process and we want to enforce the following business rules:

    • If stage = 2) Qualify then make Estimated Close Date field required
    • If stage = 3) Closing then make Estimated Close Date and Estimated Revenue fields required

    In the UI the user would see the requirement level change dynamically when he or she changes the Status Reason field value and clicks elsewhere or tabs out of it.

    Opportunity_required_fields

    To achieve this feature with Formula Manager, we would build a formula that references the statuscode ID values and the schema names of the fields we want to set as required. Something like the following if-statements:

    if(([opportunity.statuscode]=’2′), SetRequiredFields(‘estimatedvalue’), if(([opportunity.statuscode]=’3′), SetRequiredFields(‘estimatedvalue’, ‘estimatedclosedate’), SetNotRequiredFields(‘estimatedvalue’, ‘estimatedclosedate’)))

    Basically what we do in the formula is first check for the stage 2, then stage 3 and finally use a default action for stage 1 to return the fields into not required status (so we also support moving backward in the stages). We’ll set the formula to run on the opportunity entity as a Client Side – Perform Action formula, tied to the source property of the Status Reason field, which effectively means it’s triggered with the OnChange event of that field as the user manipulates the form values. (more…)

  • The Next Dynamics CRM User Experience: Orion

    Post updated 2013-06-26:

    Hi there, thanks for your interest in Orion, the next version of Microsoft Dynamics CRM. You’ve probably arrived here by following a link that promised to show you what the user interface of the upcoming application release was going to be. Unfortunately you won’t find that content here anymore.

    Back in March 2013 several Microsoft representatives presented a preview of the upcoming release at the Convergence 2013 event. It was the first time that Orion was publicly shown to MS partners, customers and anyone interested enough in the product to either attend the event in New Orleans or watch the webcasts through Virtual Convergence. I enjoyed the latter ones and took a few screenshots from those sessions (which can still be accessed through the aforementioned site. Based on them, I wrote my own analysis of how the upcoming user interface changes were going to impact Dynamics CRM users, consultants, developers and so on.

    It turned out to be quite a popular post. As I write this update on June 28th, the page had been viewed over 11,000 times. Links to the post had been shared almost 300 times on various social channels. Several Dynamics CRM experts contributed to the discussion on the Orion UX changes in the comments section, on LinkedIn and elsewhere. In short, it was a hit.

    Linktally_analytics_Orion_UX

    The reason why the post cannot be available for you to read anymore is that three months after its release my employer has signed an agreement document and the contents of my (personal) blog is seen to be in conflict with the terms of this agreement. I understand the reasoning behind this interpretation and have no problem removing some of the content based on the request I’ve received. After all, I think the post has already done its job in distributing the publicly available information from Convergence 2013 in a structured format that has hopefully made it easier for anyone working within the Microsoft Dynamics CRM ecosystem to understand the direction where the product is heading in its upcoming release.

    We’re approaching the moment when Microsoft will be making official information available about the Orion release. At that point there will no longer be a need for any preview screenshots of the UI. If you simply can’t wait for that moment to arrive, then luckily this is the Internet and it does a great job in distributing information to anyone who can be bothered to search for it. If you want to stay on top of the latest news around Microsoft Dynamics CRM, one source of information to keep an eye on is the Surviving CRM Google+ page. If you want to know, how to prepare for Orion, there are some fine articles written on the topic 😉

  • Side effects of the Polaris UI

    Side effects of the Polaris UI

    Here are some of the gotchas you can expect after switching to the new UI that is introduced in December 2012 Service Update, known by the friendly name “Polaris” release. I previously compiled a summary of the changes in the new UI and publish it as the “What’s New in Polaris” slides, but I thought I should highlight a few situations that may come as a surprise when trying to adapt your existing CRM processes onto the updated user experience of Polaris.

    Relationship attribute inheritance

    As I’ve written earlier, the new forms don’t work all too well with the concept of adding child records from the parent record’s form. Previously in CRM 2011 the ribbon provided a rich, extensible set of actions you could perform on a view of related records or a form subgrid, say contacts related to the parent account or quotes related to the opportunity. While the new Command Bar is about to take the ribbon’s place as the menu of available actions for the main entity form, there’s nothing yet in place to provide similar functionality for related records. Given that CRM by nature is all about managing relationships between different objects, this currently presents quite a severe limitation on the application’s ability to fulfill its purpose.

    “Hey, don’t we have those new plus signs on the subgrids that we can use for adding related records?” Unfortunately the answer is not quite as simple, because the actions the button offers are unconfigurable and in most cases suboptimal. Here’s a take from the CRM Online Resource Center article on customizing the forms in the new sales process:

    You may add sub-grids to the new process forms as you would with existing entity forms. Note that the behavior of the “+” sign in the new sub-grid will vary, depending upon which controls you have in place on the form. Note that sub-grids cannot be customized to display charts.

    • Add Existing and Add New, both. If both are present, the “+” sign control will function as Add Existing.
    • Add New only. The “+” sign will open a new record form.
    • Add Existing only. The “+” sign will open the classic lookup dialog box.

    In most cases we have both options available, which means that instead of the new record form we’re given the Add Existing dialog. Imagine the most basic CRM scenario of them all: adding new contacts for an existing account. Here’s what you get from the form subgrid when clicking the plus sign:

    Polaris_add_related_contact

    Ok, so it’s not exactly as nice and clean as getting a new contact form right away (the classic experience), but guess we could live with that, since there’s a “New” button available there anyway. However, this reveals one of the hidden but nasty side effects of Polaris: the relationship mappings that you’ve defined in your 1:N Parent Customer relationship between the account and contact entity are not respected when using the New button in the Add Existing dialog. This means that your new contact record will not inherit any values from the account you currently have open, including common fields like address and telephone information. Even the Parent Customer field will be empty, as the system no longer understands the context in which you are adding the new record into the database.

    This shortcoming of Polaris renders many common use cases unnecessarily cumbersome. For example, try sending an email from the web UI to a contact record using the new process forms. Although a user who’s completely new to Dynamics CRM might accept the fact that he or she needs to always navigate back to the main window and choose the type of record to create, then fill out all the lookup fields and other non-inherited values, selling this to an existing user of the system would be very tough.

    Opportunity products

    The new process form for the opportunity entity does not show the opportunity products or quotes subgrids/sections by default, you’ll need to enable the visibility in form customization to menu to show them. Once you do, the layout is not very attractive, so you may want to do some clean-up on the form sections. After this exercise you can start to leverage the familiar functionality of adding line items on the opportunity record. No, inline editing of the opportunity products still isn’t possible, but maybe it will one day be in a future release.

    As we add more product lines on the opportunity we start to notice that the total amounts are no longer up to date with the latest additions. In the previous UI we would have reached out to the ribbon to click the Recalculate button to force the system to update the record. The new Command Bar doesn’t offer such an option, however. We can’t click the save button either, as there’s nothing to be saved on the actual parent opportunity itself. Our only options to get the totals updated are to A) close and reopen the opportunity form, or B) update any arbitrary field on the opportunity form. In fact, we might as well create a new checkbox field on the form called “switch to update”, to be changed each time we want to perform the calculation. The new auto save feature will then (in no more than 30 seconds) retrieve the updated value, without even flashing the form.

    Polaris_opportunity_products_small

    Recalculation is not the only issue here, however. Referring to the relationship attribute inheritance problem that the Polaris UI suffers from, this manifests itself also in the further steps of the sales process. Suppose you’ve added a subgrid for quotes on the opportunity form (or rather made it visible), to allow you to proceed with preparing an offer document to the customer. Clicking on the plus sign works nicely here for a change, since there’s no Add Existing option available for opportunity quotes, so we’re presented with the quote record containing the right header level sums and discounts we entered on the quote. We then click save and… WHAT?!? Where did all my monetary values disappear?!  Why is the quote empty now?

    Polaris_quote_products_missing

    The reason this happens is that the quote products were never created. The lack of inheritance doesn’t only limit itself to actions the user performs on the UI, but apparently some of the platform functionality also gets broken when using the Polaris forms. The Add New relationship does carry over the total values from the opportunity form onto the quote form, but none of the line items on the opportunity get added onto the quote. This means that the moment you click save and an update form is opened, the recalculation of the quote level fields takes place, thus deleting the values that existed while we were still on the create form. Sure, you could retrieve the products from the parent opportunity by using the Get Products button on the quote ribbon (as this entity still has the classic experience), but you probably wouldn’t be very happy with this workaround, knowing how it used to work before.

    As a part of the Polaris update, the default value of the Revenue field has been changed from “System calculated” to “User provided” in Polaris, as outlined in article KB2806842. I think that sends a clear signal: if you’re working with line items in your sales process, you’d be better off not enabling the new process forms. In which case, don’t forget to go and set the default back to “System calculated” after the update if that’s how you build your opportunities. (more…)

  • Now blogging on MSDynamicsWorld.com, too

    Now blogging on MSDynamicsWorld.com, too

    In addition to the Surviving CRM blog right here, I have recently also published a few writings on MSDynamicsWorld.com. If you’re not familiar with the site yet, then I recommend you to take a look at their offering and subscribe to their newsletters. In short, MSDynamicsWorld.com is an independent online publication (meaning: not sponsored by Microsoft) that publishes content for Dynamics CRM & ERP users, partners, independent software vendors (ISVs) and consultants.

    The articles I intend to write for MSDynamicsWorld.com will be somewhat different than the blog posts you see on Surviving CRM. In my own blog I tend to cover the types of topics that I run into as a part of the day-to-day job of a Microsoft Dynamics CRM consultant: how to do X with Y, workarounds to common issues, updates on the new functionality to be expected from Microsoft & partners, etc. I speak my mind on both the good and the bad, the highs & the lows, in an effort to spread awareness of how anyone working with or around Microsoft Dynamics CRM can make the most of this great platform.

    How I’m hoping to leverage this new channel that’s been graciously offered to me by the editors of MSDynamicsWorld.com is to broaden the scope of discussion and look at the world of CRM and Dynamics CRM from a slightly different angle. Instead of the hands-on, application level topics, I’m planning to allow myself some space to move onto a higher level of abstraction and share some thoughts on the business impact and considerations involved with implementing, developing and, at the end of the day, just living with a CRM solution at the customer organization. Don’t worry, it’s not going to be too far detached from the everyday reality. I promise!

    My first articles published on MSDynamicsWorld.com are actually series of articles under the theme The Design Language of Your CRM Solution. It’s a journey through the many considerations involved in improving the user adoption rate of CRM systems – a hot topic that never goes out of style, right? I started thinking about these user adoption challenges once again when I heard Bill Patterson make a statement in his WPC 2012 presentation about designing CRM systems that can go viral. Contrasting that with the traditional world of enterprise applications (anti-viral almost by definition) gave me enough food for thought to come up with the following articles:

    • Part 1: What does it actually require to build a CRM application for viral adoption vs. top-down enforcement?
    • Part 2: Common sense design principles for making your CRM system easier for the users to adopt
    • Part 3: The importance of visualizing the processes that the users are expected to follow
    • Part 4: How the new mobile device clients are helping to make CRM a more lightweight, context-aware application

    You’ll need to create a user account at MSDynamicsWorld.com in order to access the full articles. I know, signing up to yet another website can feel like a bit of a burden, but considering it’s an independent publication that doesn’t charge their readers any money, I personally understand the requirement of creating a user account to get access to the content. I’ve signed up for the site already years ago (4.5 to be precise) and haven’t ever come across any messages from them that I would have considered spam emails not relevant to my areas of interest.

    Anyway, the choice is of course yours, but I at least encourage you to circle MSDynamicsWorld.com on Google+ or follow their RSS feed, as it’s a great source of news for all things related to the Microsoft Dynamics ecosystem. Oh, and while you’re at it, do make sure that you’re also following the Surviving CRM Google+ stream where I personally share the most interesting blog posts and articles I’ve encountered while surfing the big waves of the #MSDYNCRM community.

  • Activity view default filter, missing due dates and how to modify the filter

    Certain entities that contain the activity roll-up feature, namely accounts, contacts and opportunities, are also equipped with a date filter that allows you to choose whether you want to see all the activities related to the record or just a selected subset. By default this is “Next 30 days”, but you also can choose between “Overdue” or “Next 12 months”, or just go for “All”. That’s the good news.

    The bad news is that this piece of helpful functionality has remained uncustomizable throughout different Dynamics CRM versions. A lot of users were annoyed with especially the same filter in the associated history view, nowadays known as Closed Activities view in CRM 2011, which used to default to “Last 30 days” and hide away all but the most recent email threads, appointments and other information that you might have been searching for. You always had to change the filter manually to “All” to uncover the historical information about the relationship with the account or contact. However, this has changed now in the latest version and “All” has become the default filter (or should I say the filter is off by default).

    That’s definitely a step towards the right direction. It’s not exactly what the response on Microsoft Connect suggests, which claims that “we’ve allowed a user to change the default filter for associated views in CRM 2011”. I’ve yet run into such a setting and neither has The Great Internet, unless Google is hiding such instructions or blog posts. It would be useful to be able to configure or remove filters that the end users don’t want to deal with, without having to resort to unsupported customizations.

    Open vs. closed activities

    History is one thing but it’s the future actions that matter the most. Until very recently, I’d say up until Update Rollup 2 of CRM 2011 the filter functionality in the open activities associated views used to be such that the default “Next 30 days” would also show any activity that was missing a due date. By default the due dates are not a required field and sometimes they are not that practical for the CRM users, as many things in the daily life of a modern information worker don’t have strict deadlines. Also, there’s no out-of-the-box functionality in Dynamics CRM to set default values for date fields either, so setting the exact due date for every task or phone call you enter on your task list may feel too bureaucratic. An activity with a missing date should be considered as “do this as soon as you can, given all the surrounding factors”, in my personal opinion.

    In the current version of Update Rollup 5 the “Filter on” value is applied in such a way that it by default hides away all activities that don’t meet the “Next 30 days” criteria. If the due date is blank, the activities won’t show under the account/contact/opportunity. This may seem quite confusing to the user, since any new activity that he or she creates for the record will appear to “vanish” into thin air after clicking “Save and close”. In the My Activities view they will still appear on the top of the list, as null values in the Due Date column are sorted on top.

    What’s even more confusing is that CRM 2011 introduces two different ways for users to navigate to related activities on the account form: the familiar associated view and the new subgrid. If you’ve been reading my blog, you’ll know that subgrids ain’t exactly what associated views used to be. They don’t contain the activity roll-up feature, so you won’t see those activities that are set regarding a child record of an account (for example, opportunities) instead of the account record directly. Just like another filter, except you can’t even change it.

    How to change the default filter value

    There’s been numerous blog posts written on the topic of setting the filter defaults on CRM 4.0, but I was initially a bit surprised I couldn’t find a working piece of Javascript to achieve this on CRM 2011. Examples like this, this or this didn’t seem to be working for me, but luckily I ran into this post on the Microsoft Dynamics CRM German forum by Andreas Buchinger. To save you the trouble of Google Translate (well, it’s not much trouble at all when using Chrome’s built-in translation toolbar), here’s a walk through of the steps needed.

    (more…)