I had a discussion today with a potential customer regarding a part of the functionality of advanced find that I thought I might share as it is not so obvious.
In Dynamics CRM 4, it is not possible, with advanced find to use the "related" entities functionality of advanced find to search for objects that are on the other side of the N:N relationship.
However, in CRM 2011 this is possible. For instance, if a new relationship N:N is created between account and contact, it is possible to use advanced find to find all contacts that are connected to a certain company.
It is not, however, possible to show column data from the related entities through an N:N relationship, it is only possible to pick columns through N:1 relationships (in that direction).
Microsoft addressed the limitation of Relationship Roles in CRM 2011 by introducing Connections. Relationship roles limit connections between accounts, contacts and opportunities only, while connections allow CRM users to create connections between most entity types.
CRM users who have upgraded to CRM 2011 from previous versions will still have their relationship roles and records, but who wants to maintain and look in two different areas for similar types of information? Why not take your current relationships and create connections from them?
This blog post will help you with that effort and help you prevent most users from creating new relationships moving forward. We’re going to use the import process to accomplish this.
1. First we need to visit the current Relationship Roles and create Connections with the same name and settings. Relationship Roles are found in Settings > Business Management. Connection roles are in the same area. Since you cannot have both screens open at the same time without having two sessions of CRM running, I exported all of my relationship roles to Excel and I will use the file to quickly create new connection roles with the same name.
2. Note that my Relationship Roles have some interesting names set for the same type of relationship found in the Connection Roles. I can simply rename the Connection Role to match my list. You will also want to verify that the Connection Role is configured to allow a connection to the same type of record that the Relationship Role used.
3. Once you have a Connection Roles for each of your Relationship Roles, we can export the Relationship Roles for importing.
4. Start an Advanced Find on the entity called Customer Relationships. Edit the output columns to include all fields. Run the advanced, then click the Excel icon and select Static worksheet with records from all pages in the current view.
Note: It would be ideal to be able to check “Make this data available for re-importing by including required column headings”, but at the time of this blog post, this was generating an error on multiple systems/servers.
5. Open the resulting file in Excel and save as a CSV file.
6. Go to CRM and click Import Data from the ribbon.
7. Locate your CSV file, verify the delimiter settings.
8. Select Connection for your record type.
9. Now it’s time to map the fields.
10. If your Relationship Roles data contains values in the Description2 field, you can set map to create the new field to store this data.
11. Map Party1 to Connected From (Lookup) and Party2 to Connected To (Lookup)
12. Map Role 1 to Role (From) Lookup and Role 2 to Role (To) (lookup)
13. This is where it would be nice to have the GUIDs for Party1 and Party2, but since we don’t we’ll have to use the lookup feature. Since we know relationship roles are limited to account, contact and opportunity, we include all three of them in the lookup.
14. For the Roles we are going to do a lookup against the name field of the Connection Roles, which should match because we did that first. (Way to go us!)
15. Finish the import wizard and monitor its progress in Settings > Data Management > Imports.
Since we’re stuck having to use the friendly name lookup for accounts, contacts and opportunities, there’s a good chance there will be some duplicate lookup reference errors. This is because the import found more than one possible record for that line. If the line is for John Smith and there are four John Smiths in your organization, CRM won’t know which one you meant.
Another error I encountered was, “The connection cannot be saved. The selected record types are not defined for use with the selected connection roles. Select a different set of records or change the connection roles.” This means I was trying to create a connection to a record type that didn’t allow it. That’s simple to fix, then export your error rows and run the import again!
After a successful import, you can run an advanced find on connections and you will see that there are twice as many records as you successfully imported. A connection record is made for each party in the relationship.
Now that we have connection records to replace the relationship roles, let’s change CRM so users cannot create new relationship roles.
Modify each security role, removing any rights to the Customer Relationship entity (under the Core Records tab) and we may as well keep the users from creating new relationship roles too by clearing all of those rights too. Now only system administrators or system customizers will be able to create new relationships, but the users will not even see them as an option anymore.
We hope you found this tutorial helpful and that you will consider moving your existing relationship roles to connections.
In Dynamics CRM 2013 there is a cool new feature that allows us to assign records to multiple users through the use of Access Teams. An Access Team is basically a sub-grid of users that have access to a particular record. This means on an Opportunity for example, where multiple sales people may be involved we can add additional users into the access team to allow them access to the record.
First I’ll walk through how to set up access teams, then I’ll explain a bit more about it.
1. Enable the entity for auto-created access teams
To get started you need enable the entity for auto-created access teams. To do this, open the customization area and navigate to your entity. In my example I will use Account. Under the ‘Options for entity’ there is a new option called ‘Access Teams’. Toggle this on, and then save and publish the entity.
Note: Once this is enabled it cannot be disabled after saving.
2. Create Access Team Template
Next you need to set up the team templates, which define what levels of access the users will have to the record. Access Team Templates are created and managed from Settings -> Administration -> Access Team Templates. By default there is already a template for Opportunity, as opportunity has access teams enabled already for use with the ‘Sales Team’.
When you create a new Team Template, you can specify the Entity to use, which will only display entities that are enabled for ‘Access Teams’. We then select the Access Rights we want to grant our users. Remember that all security is additive, so if the users are given Organization Write access in their security roles, but we don’t give them Write access here, they will still have write access on the records.
We can also define multiple Access Team Templates for a single entity, however at the time of writing this blog post, using more than one template on the same entity still has some bugs. Supposedly this will allow us to configure multiple sub-grids on our form to define different levels of access for different groups of users.
3. Add Users sub-grid to entity form
The last step is to add a sub-grid to the form so you can associate users into the access team. This step has a bit of a trick to it, which wasn’t obvious at first. When configuring the sub-grid; you need to select ‘All Record Types’ instead of related only. You can then select the ‘Users’ entity. Finally the tricky part is that you need to select the ‘Associated Record Team Members’ view, which will then display a ‘Team Template’ field which allows you to select the team template to use for this sub-grid.
Note: changing an existing sub-grid will not work, so you’ll need to add a new sub-grid.
Once you’ve added your sub-grid you can save and publish the form and then try it out. You can see below I’ve added the ‘Owners’ sub-grid to the account form, and associated a couple of users using the ‘+’.
Note: The actual ‘Owner’ of the record will not change when using Access Teams.
So how does it actually work? Where are these users stored? How are they given access?
If we do an advanced find on ‘Teams’ we can see there’s a new filter added, which excludes teams of type ‘Access’ by default. If we simply remove this filter, we can now see a team with a GUID name. Upon opening this team, we can see the users we associated are added as members. On closer inspection, the Team Name (the GUID) is actually the ID of our account record. From here we can also modify the team members, which will directly update the sub-grid on our account form.
As for ‘how’ the team gains access to the record, it doesn’t seem to be ‘shared’, so this is still unclear.
Important things to note
- If you delete the physical team record, the account in my case will be reset as if there were no users associated in the sub-grid. As soon as you add a user back into the sub-grid, a new team record will be created. Note that the physical team is not deleted if you only remove the users from the sub-grid.
- Modifying the Team Template access rights will not affect existing teams. Only new records/access teams will inherit the updated permissions.
- Records will not display in ‘My’ views, as these views are filtered by ‘Owner = Current User’ so users granted access via Access Teams will have to view ‘All’ records to see them.
- To delete a Team Template, any sub-grids that reference the team template must first be removed.
Overall I think this feature will be really useful when configuring security models, as it gives us another depth of team access which wasn’t quite there in CRM 2011 using just teams.
Being able to copy a workflow in your CRM system can be advantageous in saving you time if you need to create a workflow similar to an already existing workflow or perhaps you want to make changes to a complex workflow but do not want to risk losing your original work. To copy an existing workflow, follow the steps below:
1. Make sure the workflow is in draft mode. If it is currently activated, select the activated workflow, click "Deactivate". Note: If you do not have ownership of the workflow, you will need to do this before you can deactivate. To take ownership, select the workflow, click the assign button on the top menu, select "assign to me".
2. Once in draft mode, open up the workflow record. Where it says "Activate As", use the drop-down list to select "Process Template". Save. Activate. The workflow will now appear under the "All Process Templates" view.
3. To create your new copy, click "New" (Create a new process), fill in required fields, and under Type select "New Process from an existing template". Select your template.
This also applies to Actions and Dialogs in CRM 2013. To copy a Business Process Flow in CRM 2013, simply open the existing Business Process Flow record, click Save As, and your copy will appear.
First, we will need to create the team. To create a team in CRM, do the following:
Navigate to Settings – Administration – Teams
The default view is Local Business Teams. This will display all the teams that exist in your business unit. To view all the teams in your organization, click on the view name and choose All Teams
Click New to create a new team
Provide appropriate values for the fields
Team Name (required) – use this field to identify the purpose and/or membership of the team. For example, “Department Managers”, “High Priority Support Team” or “Enterprise Sales”
Business Unit (required) – select the business unit for which this team will be a member. If you are assigning a security role to the team, select the Business Unit that has the security role you wish to assign. The members of the team do not need to belong to this business unit
Administrator – this is the person that is primarily responsible for the team
Team Type – you have two options, Owner or Access Team. We will discuss Access Team in another post. For this example, select Owner
Description – enter a summary describing the intended purpose of this team
Click Save to create the team record in CRM
Once the record has been saved, you can add team members using the sub-grid on the form.
You can add users from other business units to this team. If your security structure is designed where users can only view records for their business unit, you can add them to a team from the business unit that contains the records you need to access.
For example, User A is a member of the West Region business unit. This user needs to have access to some accounts in the East Region business unit. User A’s current security role only allows business unit access to accounts. This means that User A can only access accounts that are part of the West Region. By adding User A to a team from the East Region, they will have access to accounts that the team does.
Teams can own records in CRM. This was a feature that was introduced in CRM 2011. In order for a team to own a record, it does need to have a Security Role assigned. To assign a Security Role to a team:
With the team record open, click More Commands
Click Manage Roles from the list that appears
On the Manage Team Roles dialog, select one or more security roles that you wish to be assigned to the team.
Click OK
Now that you have a team with a security role assigned and members added to the team, you can now assign records to that team. To assign a record to the team, do the following:
Open the record that you want to assign to the new team
Click Assign on the command bar
On the Assign dialog, select Assign to another user or team radio button
Click on the Lookup and search for and select the appropriate team
Click OK
Once the record has been assigned to a team, all the members of that team essentially own the record and will have access to it. They will now be able to see it in lists of records. The actions or privileges they have to the record will depend upon the security role assigned to their team.
Our CRM experts can help you will planning and implementing your Security in CRM. Look for our next article where we feature using Access Teams in CRM as another option for handling Security Exceptions in Microsoft Dynamics CRM.
Creating workflows in Microsoft Dynamics CRM 2011 can lead to more efficient performance and consistent business practice. Understanding how to effectively use the workflow process step editor is key to successfully designing and implementing any workflow. The step editor toolbar allows you to add and organize various steps to your workflow giving it action and logic. If you are just starting to explore workflows, please read my previous post entitle Creating Workflows in Microsoft Dynamics CRM 2011.
When adding a step, Dynamics CRM 2011 allows you to enter a brief description. This is not required, but highly recommended for use when reporting and monitoring. Each step can be better understood from an organization stand point.
The steps available to add are:
Check Conditions
Wait Conditions
Workflow Actions
Stages
Check Conditions Check conditions are a means of creating guidelines for a step in your workflow. These conditions control when certain actions will take place. Criteria you specify will tell the workflow to take action and complete or ignore a step, basically managing workflow logic.
There are three options for check conditions:
Check Condition – an if-then statement.
Conditional Branch – an otherwise-if-then statement.
Default Action – an otherwise statement.
The Condition branch and default action options are only available to use in steps where a check condition already exists. To configure the check conditions using the familiar advanced find interface. (Learn more about the Advanced Find feature)
Wait Conditions
Using wait conditions will allow your workflow to run off certain time specifications. For example, creating a task to follow up with an opportunity relative to the date it was created on or sending an email a certain time after a status changes. Creating a wait condition uses all the same setup as a check condition with the addition of one more feature. The Timeout feature allows the workflow to wait a designated period of time before continuing. See example below:
Workflow Actions
Once your conditions are met, the workflow process with meet those conditions and take action according to your specifications. The workflows actions can be added by clicking ‘Add Step’ and selecting one of the options listed below:
Create Record
Update Record
Assign Record
Send E-mail
Start Child Workflow
Change Status
Stop Workflow
Custom workflow actions
Create Record – this action is pretty self-explanatory, it will create a record inside Microsoft Dynamics CRM. For example, you can create a lead record, new activity, and any custom entity records you may have. After selecting the Create Record action and choose the entity, select the ‘Set Properties’ button. From here you can specify default and custom attributes for your created records. Update Records – this action will change one or multiple records in Microsoft Dynamics CRM when your conditions are satisfied. Choose the entity, then select the fields to be changed/updated and enter their new values. Always make sure if a workflow updates a record that it isn’t setting off other unnecessary workflows or plug-ins. Assign Record – the actions will allow you to change the ownership of a record. Use the ‘Edit Assign Step Parameters’ window by selecting ‘Set Properties’ to lookup a team or user and using the dynamic values for a more advanced assignment. Send E-Mail – this action will send an email. You can use an existing email template already set up in Microsoft Dynamics CRM or formulate a new email. click the ‘Set Properties’ button to define attributes such as the To, From, Subject, and Body of the email.
*Note – A good tip to remember when sending emails through Microsoft Dynamics CRM 2011 is always test the email by sending it to you first. This way you are able to edit mistakes before sending to important clients or customers. Also, you aren’t allowed to insert (with a button) hyperlinks or images to body of the email, but you can cost/paste the URL of the link and/or copy/paste the Image into the message.
Start Child Workflow– this action allows you to start another workflow process. To use the child workflow you use must have the option ‘As a child workflow’ selected in that particular child workflow. Utilizing child workflows can save you time when you have a large number of workflow processes running in Microsoft Dynamics CRM. Having one workflow makes things easier for editing if you find that many different workflows run the same subset of process. Change Status – this action can change to status and status reason of any record in Microsoft Dynamics CRM. Records the process can change include: a record created in the workflow, the record that triggered the workflow, or a related record. Stop Workflow – this action would be used in situations where you need a workflow to stop in the middle of its process when a condition is not met. There are two options to choose from when using this action:
Succeeded – Halts the workflow immediately with a status of succeeded
Canceled – Halts the workflow immediately with a status of canceled
Using this feature allows you to make sure Dynamics CRM closes all your processes completely. Custom Workflow Actions – this action allows you to access any plug-ins you may have on your Microsoft Dynamics CRM platform. These actions will appear in the step editor after they are registered with the entity used in your process.
Stages Stages are basically groups or bundles for your workflow process steps. Select ‘Stage’ from the ‘Add Step’ menu and include a description as recommend before for each individual step in the process to stay organized. Grouping your process steps in Stages will allow your workflow to progress through without proceeding to the next group before completing the current stage.
Learn how to create these powerful business processes inside Microsoft Dynamics CRM 2011 by reading about Workflows, Dialogs, and the differences between them.
CRM 2013 introduced Business Rules, which allow you to make changes to form fields based on other field values. This allows you to show and hide fields, change what fields are required/optional and manipulate field values on forms. Some fields in CRM, such as OptionSets, allow you to natively set a default selection when adding the field to the form. However, what if you want to default something in a text, numeric or lookup field? This used to require writing custom JavaScript, but now you can use Business Rules to easily set default values on forms.
Here’s how to do it:
Open the form in the Form Editor
On the Ribbon, click Business Rules
In the Business Rule Explorer, click New Business Rule
Add the following Condition: “If (field) does not contain data”
Add the following Action: “Set (field) to “(default value)”
Save and Activate the Business Rule
Publish your form
Now your business rule will automatically fill in the default value you specified during create or if a user attempts to blank out the field. Easy as Thanksgiving pumpkin pie, with no JavaScript to write!
The NDA is off, and the next version of Dynamics CRM is due in the next couple of months. Its official name is Dynamics CRM 2013, but if we named software the way we do movie sequels, I’d recommend “Dynamics CRM 5: The Process Edition”. Yes, I know the new flow UI is getting all the attention, but for my money, business process enhancements are the biggest and most important new feature area.
The term business process is so generic-sounding it’s easy to miss its important meaning in Dynamics CRM speak: it refers to a category of customization techniques that allow you to implement processes in CRM. To understand the evolution of the terminology (and more importantly, the functionality), let’s take a little spin down CRM memory lane:
In Dynamics CRM 4.0 and prior versions, we had a single kind of business process. We called them workflow processes, and we knew that they were background processes that ran asynchronously, could be triggered by events or manually, and did not support user interaction as they ran.
Dynamics CRM 2011 added dialog processes to the business process mix, and dialogs are everything workflows are not: they run synchronously, require user input to start, and feature a wizard-like forms experience that must be run from start to finish. This necessitated a formal designation of the term business process as referring to a category of things. So we can say that CRM 2011 contained two specific types of business processes: dialogs and workflows.
Now comes Dynamics CRM 2013, with two brand new types of business processes (actions, and business process flows, and at least one very significant enhancement to an existing type (real-time workflows). Hence the need for an article like this one. (That is: I needed to write the article, just so I could figure it all out.)
The following figure provides an illustration:
As in previous versions, when you create a new business process you must specify the category. In CRM 2013, Action and Business Process Flow are the new options. (Real time workflows are specified within the designer, when you’re building a workflow process. You’ll see that below.)
Two more background points before walking through the new business process features:
Business processes are for business users. They are one of several ways you can extend and customize Dynamics CRM. The platform supports many other customization techniques (custom fields, entities, relationships, Jscript for form events, plugins) which are typically performed only by developers or administrators. Business processes are different, in that they are intended to be built by people who are not developers. Developers can certainly extend business processes, and interact with them programmatically, but you don’t need to be a developer to build the business processes this article’s about.
Business processes are different from business rules. This is another terminology issue: business processes are different from business rules. Business rules -- yet another new customization technique in CRM 2013 – give us a no-code way to implement dynamic form behavior, and with certain limitations can be used as an alternative to Jscript. So you can think of these as another delegation of customization capabilities to non-technical users…but don’t confuse them with business processes. (For more information, here’s an article I wrote recently on Introducing CRM 2013 Business Rules.)
Now that we’ve got the context and terminology, let’s see what cool new stuff Dynamics CRM 2013 has to offer in the way of business processes.
Business Process Flows
Business Process Flows are a new type of process in Dynamics CRM 2013. They provide a visual presentation of a process, in a special area at the top of a form that displays the stages of the process as headings across the top, and within each stage information that should be provided before proceeding to the next stage.
For example, the following figure shows the default CRM 2013 lead form, with the process flow area highlighted.
For a user, it’s visually obvious what needs to be done at each stage, and after the information is provided the user manually advances the process to the next stage by clicking the Next Stagebutton on the ribbon.
One of the most interesting thing about business process flows is that they can span multiple record types. Take another look at the lead form in the previous figure. It’s not obvious the first time you see it, but everything past the Qualify stage of this 4-stage process happens on the Opportunity form!
Suppose you qualified the lead, using the built-in button at the top of the form. The next thing you’d see is the following figure:
Quick: can you tell the difference? You’d have to be looking pretty closely, which I suppose is the point. Business process flows effectively make the process more important than the record type.
The authoring experience is pretty simple. For example, if you clicked the MORE COMMANDS(…) menu on the opportunity form, you could select Edit Process from the menu you see here:
I’ll save a detailed treatment of the authoring process for another article; for now, take my word for it: it’s easy.
One of the reasons it’s easy is that business process flows really don’t do very much. They don’t create or assign records, they don’t have conditional logic. Basically, they let a non-technical user associate fields (referred to as “Steps” in the process designer) with a stage, so that they show up prominently in the process area at the top of the form. For example, consider the following figure which zeroes in on the process area for the Propose stage of this (slightly customized) process:
Identify Sales Team, Develop Proposal, Complete Internal Review and Present Proposalare just fields on the opportunity entity, and the process flow designer gives a non-technical user an easy way of making them prominent and associating them with a stage. This red asterisks in the figure illustrate one more somewhat subtle benefit of process flows: the ability to require fields at a specific stage of a process. This would have required code in the previous version, and now in CRM 2013 we have two no-code ways of doing it (the other being business rules).
I mentioned above that business processes are intended to be authored by non-technical users. The default security roles in Dynamics CRM 2013 reflect this intention: all of the manager roles (name contains “Manager”) and anything above have permissions to activate one of these business process flows.
I like business process flows, and I think organizations will get plenty of value from them. This is all still new, and I won’t claim to have it fully groked yet. But I’m not as pumped about business process flows as I am about some of the other new business process features (e.g., the next topic), and I think the reason is that they don’t seem to solve problems I encounter very often. For now, I put business process flows into the new feature category of Hats off to the product team for coming up with this totally brand new approach that none of us really knew we needed, but that will probably turn out to be indispensable and end up making me look foolish for not immediately appreciating its utility.
Real-Time Workflows
These things, on the other hand, get me all fired up since they solve problems I do encounter every day. Real-time workflows – just as it sounds they should – run in real time. To appreciate the significance of this, it helps to have some experience with workflow processes in previous versions, which always ran “asynchronously”, i.e., not in real time. One of the drawbacks of this was the user experience: typically 15-30 seconds elapsed between the triggering action and the visible result. What this meant was that workflows weren’t really suitable for functionality requiring a snappy UI.
But that all changes with real-time workflows. Referring to the following figure, let’s take a look at a simple example that illustrates how useful these things will be.
This is a screenshot of a slightly customized opportunity form, and let’s suppose it describes three requirements our business users have come up with:
When a user selects a value in the Account lookup field, information from the account record should display in the Account Information section. (The fields in this section are custom, and they map to corresponding fields on the account record. If you always created opportunities from the context of the account/customer form, you could accomplish the same thing with custom field mappings. But the workflow approach covered here allows you to get these fields filled in when the opportunity is created “from scratch” – a pretty common situation.)
The Weighted Revenue field should display the product of Est. Revenue andProbability.
Rather than being entered manually, the Topic field should be auto-filled, using theOpportunity Type and the Account fields to implement a standardized naming convention for our opportunity records.
Requirements like these could be satisfied using workflow processes in previous versions…but not very well, since the lag time characteristic of async workflows doesn’t really work for things that users want to happen in real time.
But a real-time workflow can do this job nicely. When you create a new workflow process, you can specify that it should run in real time by de-selecting the (recommended) Run this workflow in the background option:
In the designer, a real-time workflow looks pretty similar to what we’re used to from previous versions, but with a couple of differences. Here’s the Process Properties section for this process:
First, notice you can convert a real-time workflow to a background workflow, and vice versa. This isn’t one of those places where you can’t change your mind.
Second, notice the “Before” and “After” options on the Start when triggers. This workflow is triggered when a new opportunity is created and when certain fields change, so we don’t have any options. But workflows triggered by status changes and deletes do have the option of running before or after the operation. This is another important advantage of real-time workflows, but I’ll save that topic for another article.
Anyway, so we’ve got a real-time workflow. What does it do? I’ll collapse the properties section to show you the workflow steps:
This will look familiar if you have some experience with CRM 2011 workflows, since it’s essentially unchanged. The Update step fills in the fields in the Account Information section, pulling them from the Account record, which is a parent of the opportunity. Next, notice the standard 3-step to calculate the weighted revenue field. Dynamic values in the workflow designer work the same as they did in previous versions, which means you don’t really have a calculated field capability.
Real-time workflows are similar in functionality to plug-ins, with the obvious difference that you don’t need to be a .NET developer to take advantage of them. One thing you’ll notice about them is that the user experience is slightly different from form script (Jscript) and business rules:
With a real-time workflow, you see the results as soon as the record is saved. In this example, if you change any of the “independent” values (say, est. revenue or probability), the “dependent” value (weighted revenue) is updated in real time…once the record is saved. In Dynamics CRM 2013 form changes are automatically saved about every 30 seconds. OR, they can be saved at any time by clicking the save button at the bottom right of the form.
With Jscript or business rules, calculations are performed as soon as field values are changed.
This alternative user experiences reflect an underlying difference: workflows and plug-ins are triggered by database events; form script and business rules are triggered by client-side events. If you’re new to this, it would be worth working through a direct comparison of the two approaches: the example in my Business Rules article does the identical “weighted revenue” calculation with the (client-side) business rules approach. The real-time workflow approach presented here is the server-side alternative.
Actions
Continuing our tour of business process newness in Dynamics CRM 2013, we come now toActions, another one of those generic-sounding words that masks the importance of the new functionality. Actions are similar to workflows in that you use the workflow designer to create them: so they can be built by non-technical users to implement business logic and processes.
But they have several differences from traditional workflows:
They can take input and output arguments.
They are not tied directly to entities: while you can specify an entity as in a regular workflow, you can also create a global action.
Finally, they can only be accessed via code: so you need a developer to write a plugin or a custom workflow to put them to use.
That last point is especially important, as it introduces a caveat to the guidance that “business processes are for business users”. The development scenario with actions is that the business user can implement the business logic, and modify it as necessary, but that the developer writes code to hook up the action to system events, passes in the right arguments and so forth.
Here are some of the most common ways actions will need to be invoked for now:
From a custom application, or an integration with another application that communicates with CRM via web services.
From code within a plugin or custom workflow.
From Jscript code, behind a form, a custom button or some other command.
Because it can take arguments and does not have to be tied to a specific entity, an Action is created at a higher level of abstraction than a traditional workflow process. For example, database developers typically think in entity-specific verbs like Create, Read, Update, and Delete. But with actions, a business user can think in terms of business verbs like “Route”, “Assign”, “Escalate”, or “Onboard New Client”.
Let’s take a look at how you might use a custom action. The following figure shows the Process Arguments section, probably the most distinctive characteristic of the action design experience:
In this example, I’m building an action that creates case records based on information from an ERP application: when an accounts receivable goes past due we want to automatically create a corresponding case in Dynamics CRM, associating it with a customer, giving it appropriate values for “Type” and “Category”, and recording the past due amount and the date it was due.
The business user knows what kind of data is needed by the account managers to work these overdue accounts; that’s reflected in the input arguments in the previous figure.
The business user also knows how these data will drive the collections process, and a simple example of that is shown in the following figure:
Here you can see the familiar step editor – identical to what we have in CRM 2011, except for a couple of things actions don’t have. (They can’t have Wait conditions, for example.)
The business user has the knowledge required to build the collections process, but certainly doesn’t know how to build an application that integrates Dynamics CRM with an ERP. Which is the whole point: the developer can provide the plumbing, and as long as the right arguments get passed in, the business process can do what it needs to, be modified as business changes and so forth.
So Many Options!
Business process flows, real-time workflows and actions are all important additions to our no-code customization toolkit. And as we’ve seen, even though business rules aren’t considered a process, per se, you can sometimes use them as an alternative way to accomplish the same thing. It’s great to have all of these new options, and I know we’ll all be discovering great applications for them in the coming weeks and months!
button at the top of the form. The next thing you’d see is the following figure:
