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!

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.

Processes: Types of Processes in Microsoft Dynamics 365

It can be overwhelming when getting started using workflows and other processes in Dynamics 365. So let's start by breaking down the types of processes that are available and how you might use these.

When creating a Process from the Settings -> Processes area you have 4 options:

1. Action - An Action is a set of steps configured by a CRM Administrator and then called through code (such as a plugin). This allows you to have an Administrator control the business logic but the developer could determine when that logic is used
• This is something to consider when you have limited access to a developer so you can minimize your dependence on them
• For example - You could have a Plugin firing when a task is added to a queue and it calls an Action to assign it to the manager. The Plugin could determine when it needs to fire, but the Action could control how the manager was set.
2. Business Process Flow - Business Process Flows allow you to create the ribbon across the top of a record that helps walk a user through a process
• The most common example is the sales process where a salesperson is guided through the Lead to Opportunity to Account process and encouraged to enter all the appropriate data along the way
• This can span multiple entities and include conditional branching logic based on input data
3. Workflows - Workflows are automated processes that fire behind the scenes
• These can fire automatically or be manually triggered by a user (on demand)
• Workflows do not allow for any user interaction in the process. It will not pop up and ask the user for more information to direct the process. It can wait on a specific action to occur.
• These can fire in the background (asynchronous) or in real time (synchronous)
4. Dialog - a Dialog is basically a wizard that will walk the user through a series of questions and then acts on the entered data
• Manually triggered on only one record at a time
• Relies on manual intervention
• Deprecated in v9 so don't get too attached

Business Rules are similar to processes in that they allow more complex logic to be achieved without code. These are configured within the entity or form that you want to work on. Business Rules ask for a condition and then allow actions based on that condition. The actions can be show/hiding a field, setting the value of a field, setting a field to required, etc. In 8.2 a "Recommendation" option was also added which allows you to suggest an action for a user and they can choose whether to implement or not.

Hopefully this gives you a high-level overview of the types of automation you can implement in Microsoft Dynamics 365!

Data Management Part 3: Cleaning Up Export for Re-Import Issues

As mentioned in Part 1: Bulk Edit and Part 2: Export for Re-Import, this material is based off my presentation done on CRMUG: The Advanced Basics: Where DO I Go Next as a CRM Admin? In that session, we covered a few topics including out of the box data management techniques. I wanted to dedicate a few blog posts to these topics to help more new CRM administrators!

Even when you are very careful there are always times that you make mistakes. Mistakes are okay as long as you know how to fix them (better if you can fix them before your boss finds out!). So here is some guidance on dealing with issues with Export for Re-import.

Failures on Import

A good kind of problem with Export for Re-Import is import failures. This just means some of your items may not have imported. This generally happens for two reasons:

1. The data was modified since you exported it. If the record changed since your export you cannot import it as you might overwrite data. To resolve, simply do a new export and update that row.
2. Lookup could not be resolved. If one of the fields you are updating is a lookup field there is a possibility that it couldn't find the record you wanted to link to or there were duplicates. With Export for Re-Import you cannot control how it searches for the correct lookup (different from a import of new records where you build the data map). It will always just look at the primary key and name. 

You can review these failures from opening the Import job and navigating to the Failures area. There is also a button here that allows you to Download Error Rows. This will give you a list of the full data row that failed so you can review and determine the best way to resolve.

Wrong Data Imported

The bad kind of problem with Export for Re-Import is when the wrong data is imported. This could mean you did some sorting and somehow misaligned the hidden GUID column and the data. Or this could even be because data was removed from the file that shouldn't have been.

I recommend the following tips when doing your export to prepare for failure:

• Eliminate unnecessary columns from your export. Then if a mistake happens you have less data to clean up.
• Eliminate unnecessary rows from your export. If possible, only export the items you expect to change.
• Save copies of your file along the way. I save a version when I export, after I do some work, and immediately before import. This allows you to have the data to fix your mistakes or see where it went wrong.

So let's say you do an export and you realize that the data imported was incorrect. You do not want to restore your database so you want to resolve with a new import. Here are the steps I would follow.

1. Start with a few deep breaths, no time for tears (flexible depending on amount of data problems)
2. Export the data that was modified with the same columns changed (remember you will be the Modified By user). We will call this NEW Export
1. Save a backup copy of this as well! Then if you get confused somewhere in this process you can quickly jump back to square one
3. Open the "Export" version you saved for the initial change. We will call this OLD Export
4. In both files expose the 3 hidden columns (A-C). A is the GUID of the record. We are going to use this to match data between the two sheets
5. For each column where data was changed, create a new column in NEW Export and do a vLookup using the GUID to get the data from the OLD Export
1. I recommend doing your vLookup in a fresh column. This will be a bit easier to manipulate (without the enforced data validation) and keeps your work separate
2. Again this is a reason to keep your columns to a minimum. You only want to do this for a few columns or it becomes hard to manage
3. Your vLookup will look something like =vLookup([NEW Export top GUID]A2,[Old Export GUID Column]A:A, [Column you want to return]4, FALSE]. The FALSE is because you want an exact match on GUID
6. Once your vLookup is complete for all columns, copy the data and Paste As Values into the correct place in the worksheet. Be careful if you have any rows that should not be changed!
1. Save this version as your Work in Progress version
7. Delete the additional columns you created. Save this version as your Import version.
8. Import this new version of the file
9. More deep breaths while it processes
10. Review the results and check for failures

It's as simple as that! Moral of the story - be very careful! Double check your changes and check the GUID you change is the correct GUID of the record you want to change before doing the import the first time.

Any better methods for cleaning up import mistakes? Any Export for Re-Import horror stories to share?

MCSA Microsoft Dynamics 365 Certification Tests

I recently took the MB2-715 and MB2-716 to achieve my Microsoft Certified Solutions Associate (MCSA) so I wanted to share my study methods to help you! I do want to preface this by saying that I am a test taker. I enjoy taking tests and do not have any kind of test anxiety. This means that my study methods could be very different from your study methods.

I am more comfortable with the customization and configuration (716) material so I planned to take that test first. I used the two courses on CustomerSource to review. These courses are "Customization in Microsoft Dynamics 365" and "Configuration in Microsoft Dynamics 365". These courses are each 7+ hours long but each section has a "Test Your Knowledge" quiz. So for the sections I already felt comfortable with I would take the quiz first then go back and watch any areas that I struggled with. For areas I was not feeling as prepared for (Interactive Service Hub, Mobile), I watched the videos first and spent extra time reviewing the questions.

In the last module of all of these courses you can download the course material. This file contains the PowerPoints and the transcript of all of the videos. In this transcript document it also has the "Test Your Knowledge" questions with explanations on the answers. This is really helpful especially on the items I got wrong and couldn't figure out.

So next I studied for the deployment (715) exam. This exam also has a course on CustomerSource called "Deployment in Microsoft Dynamics 365". I am not as familiar with these topics because most of my experience is On-Premise not Online. So I watched the full training (about 2 hours) and again spent a lot of time reviewing the "Test Your Knowledge" questions. (Funny thing: when you watch the training the questions are easier!)

Finally I read through several of Neil Parkhurst's 715 prep blogs. These are broken down by topic so you can review the areas you need help with. It was a great way to clarify some confusion and iron out all the details in my mind.

I'm also one of those people who doesn't study the day of a test. So I got a good night's rest and then just tried to relax and do my best. You can do it too!

What other ways do you have of studying?

Data Management Part 2: Export for Re-Import

As mentioned in Part 1: Bulk Edit, this material is based off my presentation done on CRMUG: The Advanced Basics: Where DO I Go Next as a CRM Admin? In that session, we covered a few topics including out of the box data management techniques. I wanted to dedicate a few blog posts to these topics to help more new CRM administrators!

Export to Excel is an awesome feature that gives administrators the power to make many changes very quickly. Since you are potentially editing a large volume of records there is also potential for a large amount of disaster. So follow these tips to make prevent as many errors as possible.

How to Use Export for Re-import:

1. Create an Advanced Find of the records you want to modify. I recommend you narrow the results to just the records you want to change and only the columns you intend to edit.
2. Export Static Worksheet (all records)

1. Note: If you are on CRM 2011 you will need to click an additional check box to make it available for Export for Re-Import
3. Pro Tip: Save a copy of this file right after export as a backup!
4. Make changes in excel
5. Back in CRM, Click Import Data and browse to the file
6. Submit the file
7. Monitor the import progress in Settings -> Data Management -> Import

Advantages of Export for Re-Import:

• Backups can be saved as you work with the data. This gives you a place to look if the final import is incorrect. The GUID is a hidden column so you can use this to match back later if necessary.
• Workflows and Plugins will still fire similar to a regular record update (compared to direct database changes)
• Excel formulas can be used to populate/edit the date (please read associated disadvantage before getting too excited)
• Read Only Fields can be edited
• Fields not on the form can be edited

Disadvantages of Export for Re-import:

• You need to be very careful when working with the Excel workbook
• Do not remove columns
• If you add columns for work/calculations - these must be removed before import
• Be careful with sorting - you do not want the hidden GUID to be associated with the wrong row of information. This could cause you to overwrite a valid record's data with data from another record. This was much easier in 2011 before the new export format.
• Be careful with formulas - it is best to do all formulas in a separate column (just remember to delete column before re-import) and then copy and "Paste as values" into the column you want to update
• Limited by the CRM Export Limits (if you are editing more records than you can export then you might want to find a way where you are not the potential single source of blame/failure)
• Cannot edit completed Activities
• You can edit some inactive records for example Won/Lost Opportunities
• Always test in a non-production environment to make sure your plan works

Also note that this will not enforce Business Rule logic that is only firing on the form (if the scope is entity, this still should run). This can be an advantage or a disadvantage depending on the case.

In addition, any record that is modified after you export will not be updated by the import. This means that if an end user updates a record the data in your spreadsheet will not overwrite that data. So you do not want to export this data and then wait a few days to do the re-import. Best to do it all at once if possible. These types of errors will be shown in the Settings -> Data Management -> Imports area.

Security Note:

On the webinar we got a very interesting question:

you've scared me a bit that users could export, screw up and re-import bad/empty data. Is this function restricted to Admins out of the box?

What a good question! No. This is not restricted to Admins. Looking at the out of the box "Salesperson" security role they have access to Export to Excel and Data Import for user owned records. So this means that they could potentially modify all of the data for their records in just a few clicks!

How have you used Export for Re-import? Any tips or warnings I missed? Any success or horror storied to share?

Data Management Part 1: Bulk Edit

I recently presented "The Advanced Basics: Where DO I Go Next as a CRM Admin?" with Patrick Wright on CRMUG (Recording available for members to watch). In this session, we covered a few topics including out of the box data management techniques. I wanted to dedicate a few blog posts to these topics to help more new CRM administrators!

Bulk Edit is a very cool feature as it allows you to quickly modify a large number of records without leaving CRM.

How to Bulk Edit Records:

1. Create an Advanced Find to isolate the records you want to edit (technically you could do this from any view of records but I recommend narrowing down your list using Advanced Find to prevent errors)
2. Select the records you want to edit or the whole page if editing all
3. Click Edit
4. Make your Change
5. Click Save

Advantages to Bulk Edit:

• All handled quickly inside CRM
• Only limited by the number of records you can view (remember you can update this in your personal options)
• All Workflows and Plugins will fire as you expect (as compared to an unsupported database update)

Disadvantages of Bulk Edit:

• Limited to only the fields on the form
• Cannot edit Read-Only fields
• Cannot clear data from fields
• Can potentially overwrite the wrong data (no undo button!)
• Ignores Business Rules that are firing on the form (thanks webinar attendee for this reminder!)

This is a very powerful tool which means there is always the possibility of a mistake! To minimize the likelihood for error, limit the number of records you edit via Advanced Find and double check your form before hitting save!

Security Note: Access to Bulk Edit is controlled by the "Bulk Edit" Permission on the "Business Management" tab under "Miscellaneous Privileges". This IS included in the out of the box "Salesperson" role so you may want to review what access your end users have if you do not want them using this function.

How have you used this in your organization? Any tips or warnings I missed?

Updated additional tips from the twitterverse:

• @SalenticaDaveI shared a reminder that only fields on the form can be edited this way (but you can use Export for Re-import). Also if you have JavaScript linked to a field this can cause issues.
• Diane @Riderfan78 shared that bulk edit can cause issues with the status/status reason on custom entities (see CRMUG Discussion for more information). This is another reason to always test your changes in a development environment and/or on a small subset of records.