Dialogs in Microsoft Dynamics CRM are interactive processes that require user input to run to completion. In order to understand a dialog, the following section will break down the basic components that make up a dialog.
Page: the most fundamental component in a dialog; it is the visual interface, and it holds most all of the interactive content in a dialog. A dialog can have more than one page.
Prompt and Response: prompts the user via a page and takes the response from the user via the page.
Variable: used to insert data-fields into a dialog, data is stored for later use.
Steps: similar to steps in a workflow,
Input Argument: works only with dialogs that are running as a Child Process. They are useful in situations where you’d like to transfer data from a parent dialog to a child dialog.
Microsoft Dynamics CRM dialogs can query data from your CRM organization, and the data returned in a query can be used in prompts and responses. You can use this method when the values are stored as CRM records. There are several advantages to doing this:
- You won’t have to type as much
- Your dialog will always reflect up to date data
- Your data will have more integrity and be less error prone
- You can create dynamic or linked queries
The response types that can take advantage of this feature are the picklist and radio buttons options. However, picklist and radio button are not suitable for queries that return too much data. For example, using a picklist to display all active accounts in your system when you have 10,000 accounts is probably not a good idea! The picklist will take a long time to render and will be difficult to use.
If you want user to be able to search and select from a look up of all active records, you must use the lookup/response type approach
If you want to provide more structure to a look up and present users with pre-filtered or dynamically filtered lists to select from, you must use Query CRM data.
A Child Process is a process that is created by another (parent) process. In Dynamics CRM, child processes can be an outstanding tool to further enhance the power of automating business processes.
Like a workflow, a child dialog can be created to link two dialog processes together. Unlike a workflow, we can use the parent dialog to pass input variables to the child dialog. We can then use these inputs in the child dialog for lookup, calculation, updates, etc.
There are two main scenarios in which child dialogs are used:
- 1. When you have a recursive Process.
- Suppose you have a dialog process that gathers information from a user and then uses that information to create a case record for an account. If you want to provide the option of creating several cases without requiring the user to select the account record and repeatedly start the dialog from the ribbon, this is a job for a recursive process, in which a dialog can repeatedly call itself as a child process.
- The most important point is that both the ‘as an on-demand process’ and ‘as a child process’ options must be selected in the Available to Run section. If the first one isn’t selected you’d have no way of kicking off the dialog in the first place’ if the second isn’t selected the dialog won’t be able to call itself recursively.
- When you have modular dialog processes you want to reuse.
- This is best used when you have certain ‘common logic’ that you want to apply against many different workflows.
- For example, what if I have logic that will assign accounts, contacts and leads based on their ZIP code? Rather than recreating this same IF…Then logic in many different dialogs, I can create 1 child dialog and then call it from the different parent dialogs.