Wednesday, March 28, 2018

Microsoft Dynamics 365 Business Rule Steps

Business Rules in Microsoft Dynamics 365 are a very powerful tool. They allow administrators to create the effects of form scripting without needing to know JavaScript (or as it is usually in my case, educated copy and paste :) ). So let's talk about what can be done with Business Rules.

Getting Started

Business Rules are created within a particular entity or can be done from within the form. When creating you can choose the scope of the business rule to be: Entity, All forms, or a specific form. Entity means this rule will be applied from all data entry points (forms, imports, API, etc.). All forms will mean that whenever data entry is occurring from the form these rules will be applied. If you choose a specific form then the rule will only apply when that form is used.

Components

Here are the steps that can be done via Business Rules:

  • Condition: If statement. Allows you to specify when the next actions should occur. You can have multiple conditions one after each other but you cannot put a condition after another type of step.
  • Recommendation: New in 8.2 and example to follow. This allows you to notify users of a recommended change. It does not force them to make the change but shows the expected change and can apply it for the user.
  • Show Error Message: Present an error message to the user. While error message is onscreen the user cannot save changes. So make sure this message explains what to do to fix.
  • Set Default Value: Set the value for any field from that entity. Change is made on-screen for the user. This can be set to a specific value or to the value of another field.
  • Set Field Value: Set the value for any field from that entity. Change is made on-screen for the user. This can be set to a specific value or to the value of another field or the field value can be cleared. So that is similar to Set Default Value and the difference depends on when you expect this action to occur (see this blog from PowerObjects to clarify).
  • Set Visibility: Show or hide fields on the screen. If you hide all fields in a section, the whole section will be hidden.
  • Lock/Unlock: Set fields to read-only or back to editable.
  • Set Business Required: Change field requirement level between Business Required and Not Required. Great to use when you want to make sure fields are required based on a specific type or category.
Recommendations

The Recommendation functionality is very interesting as it allows you to encourage the users to do something without forcing the change. So exceptions can still be allowed.

In your business rule you will choose the Condition when this recommendation will apply as well as the message details to display to the user and the change you want to occur.

  

Then when that condition is met an idea icon shows up next to the field the Recommendation is on.


If users click this icon, they will see your defined message.


Then they can choose to "Apply" your recommendation and make the change automatically. Or they can click "Dismiss" to ignore your suggestions.


This Recommendation functionality has lots of potential uses and can be used in combination with other Business Rule steps.

How do you use Business Rules? Any cool solutions?

Tuesday, March 27, 2018

Scribe Online Documentation Tool

If you use Scribe Online with Microsoft Dynamics 365 (or any system really) you need to check out their Google Docs Documentation tool. Start with this article on how to use: https://dev.scribesoft.com/en/g_docs/doc_maps.htm

From inside a Google sheet, you will login to Scribe Online and then it will magically pull down the details of your integration. This will include all of the steps with any queries, steps, field maps, etc.

This has saved me so much time since I learned about it. No more (or at least less) time spent detailing everything the integration is doing, just look like you worked really hard on it. Then take yourself out for coffee.

Solution overview

Step Details

Saturday, March 24, 2018

Getting Started with XrmToolBox

XrmToolBox is a great tool for administrators. It has lots of great features to make your life easier. For me, it was a bit intimidating getting started so let's talk about how to do it. Then I will talk about a few of my favorite tools.

Step 1: Download the tool

Download the latest version from: https://www.xrmtoolbox.com/
This will download a .zip file. Extract to anywhere convenient on your machine.

Step 2: Launch the App

Open the extracted files. It will looks something like this. Double click on the Application to launch. This does not need to be on the CRM Server or installed. Just launch.


Loading. Wait patiently.


Step 3: Install Additional Plugins

Don't be crazy we are just getting started! You can close this page.
Later you can use this step to add additional tools that are not downloaded by default. You can also launch this once in the app through Tools -> Plugin store.
But for now, just stay calm and close this window.



Step 4: Set up your Connection



Now you will link to your CRM implementation. You can store multiple connections (such as a development environment and production). Remember to test everything in a development environment. If possible, use the tool to make changes there then use a solution to move to other environments. But that's a topic for another time.

  1. Click the "Connect" Button in the top left
  2. Select "New Connection" in the new window
  3. Enter the URL for your CRM instance. If you are on-premise, then you can check off "Use your current credentials" to login with your domain login. Click "Go" to proceed.
  4. If online, then enter your username and password to login. You can also select "Save password to encrypt string in connection file" so you do not need to enter your credentials again in the future.
  5. Wait patiently.
  6. Enter a name for this connection. This should be something that will help you know which environment it connects to.
  7. You will notice the bottom of the screen updates to show the connection.
Step 5: Start working!

Now, just go to the Plugins tab and start seeing what magic you can do!



Metadata Document Generator

This is one of my favorite tools as it saves me from typing and copying things unnecessarily! It allows you to grab all of the attributes and their details from all entities in your CRM system.

To use start by selecting "Retrieve Entities and Languages" to pull in the data from your CRM system. Then select an Excel file to populate with this data (blank, everything will be overwritten). Select the entities you want to extract the data from or all entities. Finally, click "Generate Document".


The Metadata Document Generator is the tool I have used the most frequently. There are lots of other great tools to check out such as:
  • Audit Center - Allows you to modify the audit settings of fields in bulk. Good idea when you enable auditing for an entity and all fields have been automatically enabled.
  • Easy Translator - designed to help you set the field labels in other languages. Also can be used for updating the description fields (aka tool tips) in bulk. (We used this when upgrading from 2011 to 2016 because many fields had descriptions saying "Created by KK on ...")
  • User Settings Utility - update default user settings such as number of records in a view and default start page.
  • View Layout Replicator - Allows you to copy the columns plus widths from one view to another. It even allows you to copy from a personal view to a system view. This is great when creating a new entity where you want all views to be consistent but you don't want to do all the clicking multiple times. 
That's all! Try it out and see what you can do!

What are your favorite uses for XrmToolBox?

Monday, March 19, 2018

Microsoft Dynamics 365 Workflows: Real Time Options

Creating a new Real-Time Workflow
I have been mentioning Real-Time workflows throughout the rest of my workflow series. Today, let's look at Real-Time workflows specifically.
Converting to Real Time from Background

Start When Options
 Converting to Real-Time


Return Error to User: Step 1
New Workflows are set to Run in the Background (asynchronous) by default. You can un-check this option when creating a new workflow or to change an existing workflow to a Real-Time workflow, click the "Convert to Real-Time Workflow" button in the Ribbon.

This button will then change to allow you to convert back to a background process if necessary.

Remember to use Real-Time workflows sparingly as these can impact the performance for the end user.
Return Error to User: Step 2

Start When Options

Real Time Delete Example Workflow
The Start options are different for Real-Time workflows because you can choose if the steps run before or after an action occurs.
Real Time Delete Example Message


Real Time Delete Returned Message

For example, you could configure it to run Before a delete occurs and use the workflow to prevent the deletion in certain situations.

The same scope and start when types apply.

Run As Options

A background workflow will always run as the workflow owner. For Real-Time workflows you can choose if it will run as the workflow owner or the user who triggers the workflow (meaning the person who created the record if running on create).

Be sure to test this setting with your end users and review the security needed to complete the tasks. If running as the triggering user and the end user does not have permission to complete the tasks in the workflow then the workflow will fail.

Returning Errors to the User

A cool feature of Real-Time workflows is that you can use them to prevent actions and return messages to the user. Let's say we want to do this in a delete scenario:

  1. Create your workflow to fire BEFORE Delete
  2. Add a Conditional Statement to the workflow, say if Opportunity: Estimated Revenue is over $100,000
  3. Add a step to Stop Workflow as Canceled
  4. Click Properties and you can fill in the message returned to the user

The properties also allows you to pull in dynamic fields. So you can say in the Alert that the delete was prevented due to the estimated revenue being over a certain amount. This same logic could be used to prevent closing an opportunity as lost without manager approval or deactivating an account without reaching out.

How have you used Real-Time Workflows? What is your favorite feature?

Monday, February 19, 2018

Microsoft Dynamics 365 Workflows: Workflow Steps

We have already learned about the Types of Processes, Workflow Settings and Workflow Scope and Trigger options. Now let's move on to what you can do inside these workflows.

The most important part of writing workflows is figuring out the correct logic and flow. To do this I recommend starting with a flow chart. This gives you a document to save as well as something for the business to sign off on. To be able to create this flow chart, you need to understand what step options you have, so let's start there.

Standard workflow steps:

  • Stage: this is purely for documentation. You can use stages to break up portions of your workflow. If you use a stage for one portion, you need to use stages throughout.
  • Check Condition: An If statement. Use to ensure you are only running the workflow for the proper records. Also can be used to create more logic.
    • Conditional Branch: An Else If or Otherwise If. In the case where the "Check Condition" was false (no actions inside have run) then check this next.
    • Default Branch: An Else or Otherwise. The Check Condition and all subsequent Conditional Branches were all false, do these actions in remaining cases.
  • Wait Condition: Wait for a particular action to occur or for a specific period of time (timeout). These should be used sparingly if possible. Also after a wait condition is a good time to call a child workflow to break up your logic.
  • Create Record: Create a new record. This can use any data for the record the workflow is based on (firing off off) or any other records created as part of the process. You can also use the process data or the current execution time (can be used to set due dates).
  • Assign Record: Change the owner of an existing record. This can be the primary record or any records created in the workflow.
  • Send Email: Send an email using an existing template or draft in the workflow. You can create an Email with the "Create Workflow" step but then you cannot send in the workflow. The only way to send is through this "Send Email" step.
  • Start Child Workflow: Start another workflow. This is a great way to break up the logic or split up the results of your conditional steps.
  • Perform Action: start an Action process. Similar to a child workflow but allows you to pass parameters into processing. These can also be called through code. (See Types of Processes for more information)
  • Change Status: Modify the record status from Active to Inactive, Open to Closed. This can be used to complete Activities or reopen Activities to edit. 
  • Stop Workflow: Mark the end of the workflow. This is generally the most useful in combination with check conditions. Run a Check Condition to determine if actions need to occur, if not then stop workflow. This is not needed as the last step of your workflow.

Now just to add some confusion there are also Custom Workflow steps. Some of these are provided as part of Microsoft solutions - such as field service, project automation, etc. In addition to these, you can install several other solutions to add additional step options. Check out Workflow Elements and the Ultimate Workflow Toolkit.

With all these options there is a large range of functionality available and no limits to the power of workflows!

Monday, February 12, 2018

Microsoft Dynamics 365 Workflows: Start When and Scope

Now you already know about the types of processes and the left-side of the workflow options (Run When), so now we will talk about the right-side of the workflow options. This includes Scope and Start When.
Background Workflow Scope and Start When


Scope means who should this run for. Start when is what action should trigger this.

A few things to keep in mind before we get started:

  1. Scope is always relative to the Owner of the workflow. If you tested and it worked for you but not others or it worked before you reassigned to a system user - you may want to review scope.
  2. By default the workflow will run as the Owner. This means that the Owner's security will determine what can and cannot be done in the workflow. For example, if the workflow owner cannot delete tasks, then this step would fail in the workflow. Exceptions:
    • On Demand workflows always run as the person who triggered it
    • Real-Time workflows can be configured to either run as the owner or the user who triggered it
  3. Who the workflow Runs As (see #2) will determine the name that is shown on the "Modified By" of any records manipulated in the workflow
    • This is a good reason to use a system user of some kind so that users do not call you (the admin, workflow owner) when their records are modified by a workflow

Scope

Here are the possible options for Workflow scope:


  • User
    • The workflow will only run for records owned by the owner of the workflow
    • The owner must trigger the "Start When" event
    • This is good to use in testing (especially if you don't have a separate test environment) to make sure the logic works for you before opening up to the rest of the organization
  • Business Unit
    • Fires for records owned by the workflow owner or anyone in the same business unit
    • Marketing wants a specific action for only their records, assign the workflow to someone in the Marketing Business Unit and have the scope set to Business Unit
  • Parent: Child Business Unit
    • Fires for records owned by the workflow owner, anyone in their business unit, and anyone in child business units
    • If your business units are arranged in a hierarchy based on business line, you could use this to run specific logic for one business line and different logic for another. Each workflow would be owned by someone in the top of that business line with Parent:Child Business Unit scope
  • Organization
    • Fires for everyone
    • Workflow is triggered on all records that meet the "Start When" conditions
    • This is the most common scope
    • Remember to always include a check condition as the first step of your workflow to make sure it only runs when necessary
Start When

Start When is very closely related to Scope. Scope determines when we care about actions, Start When determines what actions we care about.
  • Record is Created
    • When a record is saved for the first time
  • Record Status Changes
    • When Status changes from Active to Inactive, or an Activity changes from Open/Scheduled to complete or canceled
    • Remember to use a check condition to determine which statuses you want to act on
    • Always test! Some entities can be edited when in an Inactive status but not all 
  • Record is Assigned
    • When record owner changes
  • Record Fields Change
    • Select specific fields to monitor for changes
    • Do not select "Modified On" especially if you are also modifying the record as part of the workflow
  • Record
    • When record is deleted
    • Consider making this a Real-Time workflow so it can fire before the delete occurs
    • If this is a background workflow you cannot prevent the delete from happening and you will not have the data accessible
Now you have all the information you need to figure out your workflow settings!

Microsoft Dynamics 365 Workflows: Workflow Settings

Now that you understand the types of Processes available in Microsoft Dynamics 365, let's break down the settings you will need to configure for workflows. It can be very confusing while working on your first workflow to see the half-page of settings you need to fill out!


Background Workflow Options
Today will will cover the left side of the settings - Available to Run and Workflow Job Retention.

Available to Run
The Available to Run Settings determine when and how this workflow should run.

When:

  • Automatically - this is determined by the settings on the right hand side and by the "How"
  • On-Demand - this means that a user manually clicks "Run Workflow" and selects this process to start
    • TIP: It is always a good idea to allow workflows to be run On-Demand while testing. This allows you to test on a smaller group of records before exposing to a larger group.
    • When running an On-Demand workflow it always runs as the users who triggered the workflow
  • Child Process - in this case, the workflow is called from another workflow. This is very helpful in long or complicated workflows where you may want to split portions of logic out into smaller sections
    • Child workflows are especially useful if you have long-running workflows with multiple wait conditions. A workflow will always run as it was defined at the time it started. 
      • For example, you have a workflow that starts when a lead is created, waits 6 months and then creates a task with instructions to call the lead
      • Say the Business decides now they want the instructions to say to email the lead instead of call
      • If all one workflow: all leads created before the change was made will still say "Call". That means in 6 months they are still getting "Call" tasks
      • If using a child workflow after the wait (creating the task): then all leads that reach their 6 month mark after the change (not just created after the change) will get "Email" instructions. When they hit the wait/timeout, it will move to the new child workflow and pick up the new task details
Real-Time Workflow Options
How: (Note: This setting is controlled by a button in the ribbon just to make it really confusing!)
  • In the Background (Asynchronous) - when the workflow is triggered it will get added to a queue of workflows that are processed in order. The change is not visible on the screen but should be complete before the next time the open the record
    • This always runs as the Owner of the workflow. This means it follows their security (can't delete if the owner does not have access to) and shows that name in the "Modified By" fields
  • Real-Time (Synchronous) - when the workflow is selected to run in Real-Time additional options will appear to define this (Scope and Start When). You can configure the workflow to fire before the save event occurs (ex. return an error to the user for validation) or before a delete (capture some data before letting the delete proceed), etc.
    • This should be used in moderation as it can slow performance for the end user. For example, the user clicks save but has to wait while the workflow runs before the screen refreshes
    • This will run before any background processes waiting to run
    • In the case of Real-Time workflows you can also switch who the workflow run as. This means who is shown as the "Modified By" and whose security is used. By default this is the Owner of the workflow except in the case of On-Demand where it is whoever triggered it. For Real-Time workflows you can select which behavior to follow.
Workflow Job Retention
At the bottom of the left-side settings there is a check box for "Automatically delete completed workflow jobs to save disk space". This determines if the "System Job", the record of the running workflow, is kept or deleted.

When getting started with a new workflow, you will want to leave this off (not automatically deleted) so that you can review and ensure things are working as expected. Once things are running smoothly you can turn on.

Keep in mind that you can (and should) also create Bulk Delete jobs on the "System Jobs" entity to clean up your complete workflows.