It’s easy enough to email another CRM user a link to a record. If you open up a form for almost any record type in Dynamics CRM, you can pull down the Actions menu and select the Send Shortcut command to do this. Dynamics CRM will open up your mail client, and insert a rather complicated looking link which the recipient will be able to click to navigate directly to the record (assuming they have read permissions!)

For example, here’s what it looks like from an opportunity record:

Here’s what it looks like for an account record:

While your specific links will be different than mine (mine are for records contained in my CRM Online database, and the nasty-looking 25-character GUID uniquely identifies CRM records so it better be different!), the general structure will always be the same. I’ll come back to that point a little later, since it will solve a problem for us.

Problem: a Workflow-generated email cannot send a record link

So…while you can use the menu command I just mentioned to manually email a link to a record, you cannot email a link to a record from within a workflow. This might sound somewhat obscure, but it actually comes up a lot, and when you run into it, it just seems like something you should be able to do! Fortunately, there’s a relatively easy fix you can implement, with just a pinch of customization and a smidgeon of script. I’ll show you the solution next, but first, let me illustrate the problem in a little more detail.

Suppose I want a workflow to automatically send an email alert any time something important changes about an opportunity record. Here are a few scenarios to illustrate:

• If the pipeline stage of an opportunity record changes, send an email alerting the sales manager.
• If the current date is with three days of an open opportunity’s estimated close date, send a reminder email to the opportunity owner.
• If an opportunity is closed as “Lost”, send an email alert to the owner’s manager.

You can come up with as many scenarios as there are organizations in the world, but in all of them, it would be nice to include a simple clickable link in the body of the email, so the recipient of the alert can navigate directly to the record in question.

As you know if you’ve read my book on Dynamics CRM workflows, there are many things you can do with Dynamics CRM workflows…but unfortunately, this is not one of them! I’ll illustrate with a simple alert email, sent by a workflow that runs automatically any time specified values of the opportunity entity change.

The following screen shot shows the Set Properties form for the workflow’s Send e-mail action. For demo purposes, the email simply goes to me, and I’ve used Dynamic Values to populate the body of the email with presumably interesting information about the current opportunity.

There is an eponymously titled field you can insert for any entity in Dynamics CRM, in this case, using the “{field name{entity name}}” characteristic of the workflow design environment, it’s the {Opportunity{Opportunity}} you can see in the figure. The problem with that is that it’s only a clickable link to the record if it’s on the Regarding field…and the Regarding field only appears if you happen to be viewing the email activity within Dynamics CRM.

Here’s what an email sent by this workflow looks like in Dynamics CRM (e.g., as a History item associated with the opportunity record):

But if, like most people as you prefer consuming your email in Outlook or a non-CRM email client, you never see that Regarding field. For example, Outlook:

Solution: A Pinch of Customization and a Smidgeon of Script (and URL Addressable Forms)

If you’ve read this far, I’m grateful, and you may have noticed the “Link to record” field that’s appeared in a couple of screen shots. That’s the solution, and it uses a technique called URL Addressable Forms, which simply means that every form in Dynamics CRM can be accessed via a unique URL, consisting of an entity-specific prefix combined with a suffix unique to a specific record. You can use the Send Shortcut command I started out by discussing to see what the prefix is for some common record types:

Common Record Types

You can use a custom attribute for any entity you want to include a clickable link for by following these steps:

1. Customize the entity in question (e.g., Opportunity) by adding a new attribute. I added a custom attribute to the Opportunity entity, called it “Record Link” (it has a corresponding schema name), and gave it the following properties:

   

    

   The most important is to make it a Type of “nvarchar”, since that’s the only type that has the clickable link format of “URL”. Make sure it’s long enough. I made mine 200, but you can always come back and increase the maximum length (unlike the type and format values, which can’t be changed once the custom attribute is created.)

1. Once the attribute is created, the question is how to put the value into it. This really is just a smidgeon of script code – one line of Jscript you can put in the Opportunity form’s OnSave event:

    

   crmForm.all.img_recordlink.DataValue = ‘https://imginc.crm.dynamics.com/sfa/opps/edit.aspx?id=’+crmForm.ObjectId;
   

That’s pretty much it. If you implement this you’ll notice that since I wrote this code for the form’s save event, the new “Record Link” field won’t contain anything until a record’s form has been saved at least once after you’ve saved and published theses customizations. Too bad there’s not a built-in Record Link attribute for every Dynamics CRM entity. I guess I should add that to my top X list of new features that should be included in Dynamic CRM 5!

I wrote a book on Dynamics CRM workflows, by the way, and it contains tons of examples like this one and other useful workflows. You can purchase the book on Lulu.com or on Amazon, and if you do, you can also get a (free) subscription to the online version of the book, where you can download the workflows themselves, customizations, and related content.

Here’s a link you can visit to find out more about my book and purchase it:

Sometimes What’s NOT there is What’s Important!

In Dynamics CRM it’s possible to delete Opportunity and Case records. (This might sound trivially obvious, but in fact there are many kinds of records that cannot be deleted, such as User, Business Unit, and others.) Even though a well-designed implementation will use security roles to guard against the accidental deletion of important data…well, you know what they say about the best laid plans of mice and men. If you’ve ever been in a situation where a number of important records were deleted, you’ll be glad to know about the technique I discuss in this article!

In Dynamics CRM 4.0, one of the big improvements to workflows was the introduction of the “Record is deleted” trigger. I appreciate from (painful!) experience the value of this trigger, but I also know it can be hard to understand at first.

You might wonder, for example, if a workflow can use this trigger to roll back (”un-delete”) a deleted record. It can’t.

So if you can’t un-delete a record, what good is the delete trigger? Plenty, it turns out, since a workflow instance triggered by a delete event contains all of the values of the deleted record! The trick is to write them out to some kind of “audit” record so you don’t lose all of the data. I’ll show you an example of that here for the Opportunity entity, and you can adapt it to your specific business requirements.  

The approach I will take here is to create a custom entity that can be used to store information about deleted Opportunity records. As you’ll see, most of the work is in creating the custom entity; once the audit entity is created, the workflow is pretty simple!

Part 1: Design and Create the Audit Entity

Start by selecting from the 36 attributes available in the un-customized CRM Opportunity entity and determining the ones you want to store values of in your audit trail. This will obviously be determined by your business requirements, and will generally be a longer list than the one I propose in this table:

To create and configure the custom audit attribute, follow these steps:

1.  On the Dynamics CRM site map, click Settings, then click the Customization tab. Click Customize Entities, then click New.
2. Name it “Opportunity Audit”, and (optionally) change the name of the default primary key label to “Topic”, so it matches up to the corresponding attribute in Opportunity.
3. Specify that the entity is to be organization-owned, that it does need support for Notes and Activities, and that it will only appear in the Settings area. Click Save. After the custom entity is saved, your entity form should look like the following:

4. After the entity is created, the next step is to add the required custom attributes. Of the six attributes indicated above in, one (Name/Topic) is already created, three (Potential Customer, Modified By, and Owner) will be created by creating custom relationships, and the Estimated Close Date and Estimated Revenue attributes need to be created “by hand”. The next figure shows what a subset of the Opportunity Audit attributes (the ones I created) look like once they’re created.

5. Rather than go through a detailed step-by-step recitation of how to create each one, I’ll provide high-level instructions here:

a. To create Est. Close Date and Est. Revenue, simply click New, enter the Display Name and select the appropriate type. Remember what you want to do is have these match up exactly to the corresponding attributes in Opportunity, so if necessary, open it up in another window to make sure!

b. The three lookup attributes (Deleted by, Owned by, and Potential Customer) provide a good example of Dynamics CRM’s custom database features. Both “Deleted by” and “Owned by” should be filled in automatically, respectively, with the user who deleted the record, and the record’s owner at the time it was deleted. In CRM 4, you can create a new relationship between a System entity like User and a custom entity like Opportunity Audit to get this done. Since we will potentially have many audit records for a single user, click N:1 Relationships, and then click New Many-to-1 Relationship. For the “Deleted by” attribute, you want the form to look like the following figure. The “Owned by” will be identical (except for the name of the attribute), and the “Potential Customer” needs to be a lookup against either Account or Contact. I’ll use Contact for this example.

6. After creating the custom attributes you want to track, you can add the attributes as fields on the entity’s form. This isn’t a real requirement, but it’s helpful to have a form to look at in certain circumstances and it doesn’t take much work, so I generally do it.

7. Finally, save and publish the Audit Entity.

 Part 2: Build the Delete Workflow

In this example, all the hard work’s essentially done. To build the workflow, follow these steps:

1. Create a new workflow with a scope of Organization and automatically triggered on the “Record is deleted” trigger. It only needs one action, which will create an audit record:

2. To populate the Opportunity Audit record with the values you need, click Set Properties.

3. Use Dynamic Values to configure the values you want. I often use a mix of static text and the audited record’s “Topic” field to construct a sufficiently eye-catching Topic. Remember this is supposed to flag deleted records and make them stand out, so in this example I included some “***” asterisks on the front of the Topic field.

4. Click Save and Close, then Publish the workflow.

Some Closing Thoughts

Test it to make sure it works as expected. The simplicity of a workflow like this one is due to its singleness of purpose, so to speak. An alternative approach is to create a more general audit capability, where you write out audit records not just for deleted records but also for important changes (changes in Status, changes in estimated close dates and revenue, etc.)

If you’re just starting out, I recommend you start with the simpler approach I reviewed here. Here’s an example of a problem you can run into with a more general approach:

Suppose you create your audit entity as a child entity of Opportunity (Opportunity has a 1:N relationship to the audit entity). This works fine if you write out an audit record on an existing Opportunity record. But if you want to keep track of deleted records it won’t work: you can’t create a child record related to a deleted Opportunity record…since the record isn’t there anymore! Not that there isn’t a way to solve this problem…but it is more complex!

If you find this useful…

This example is taken from my book on Dynamics CRM workflows, cleverly titled “Workflows in Microsoft Dynamics CRM 4.0″. It’s available for purchase on Amazon and Lulu.com (cheaper on Lulu). Here’s the link if you’d like to purchase the book:

I’ve written a few times about integrating Internet marketing into your overall Dynamics CRM marketing efforts. In particular, one of the big gaps in the traditional feature set was the lack of a web-to-lead function so real “marketing types” could capture leads from a web form directly into Dynamics CRM…without having to write code to do it! So, let’s start with

A Review of Internet Lead Capture for Dynamics CRM

This problem now has some good solutions, and one that I particularly like — Web2CRM from CRM Innovation at http://www.crminnovation.com — is the starting point for this article.

To quickly review, what Web2CRM lets you do is create an Internet page with a form on it, into which a visitor can enter information, and from which you can pop the information directly into your CRM. One big advantage of the Web2CRM product, compared to (for example) the Microsoft implementation in CRM Online, is that Web2CRM lets you create a web form for ANY entity in your Dynamics CRM, including custom ones! So while the CRM Online approach only lets you accept Internet Leads into the new “Internet Lead” entity, Web2CRM gives you a sweet drag and drop form designer you can use to create a web form to populate any entity.

For example, here’s a look at the Web2CRM form design environment. In the next figure, I’ve already selected the entity I’m designing a form for, and I’ve got a nice drag and drop environment I can use to select any of its fields to place on the form. You get a nice design-ish view of your CRM form on the left hand side, from which you can drag and drop fields onto the Web2CRM form-in-progress in the middle. At the right, you can see which entity the form’s being designed for, and you get some other form-level settings I won’t go into here.

If you click the Publish button you get a very generic form that is hosted on the CRM Innovation servers — another example of the hosted “software+services” model. But if you click the cryptically named “Carry Code” button you open up a window with a bunch of script code you can simply copy and pasted onto one of your very own pages, and create a page on your site that looks like this one (or however you want yours to look!):

To review, the form is created for the “Info Requester” custom entity I created in my CRM organiztion. So if you fill out the form you will find here —  www.DynamicsCRMTrickBag.com/request-content — a new record gets created in my CRM with the information you provide.

So…on to the main point of this article…

What to do with those Internet Leads?

One good thing to do is to send an acknowledgment email — often referred to as an “auto-responder”. In Dynamics CRM, one of the seven actions a workflow can take (can you name the other six?) is to send an email, so I can create a workflow to run automatically when a new Info Requester record is created and send a nice auto-responder. But…you can’t email directly to a custom entity (yet!) in CRM 4, so the first thing my workflow has to do is create a Lead record based on the Info Request record. So here’s what my simple workflow looks like:

The “Create Lead” action simply takes the fields entered onto the web form, and pops them into the corresponding fields on a new lead record.

You can use dynamic values to configure the “Send e-mail” action, crafting a somewhat customized and oh-so-responsive response! Like this:

And last but not least, notice the Attachments tab in that figure. You can attach one or more items to a workflow-generated email in Dynamics CRM 4, so depending on what kind of information people might be interested in receiving — a white paper, say, or even a Dynamics CRM workflow all zipped up and ready to go — you can include that in the response as well.

If you want to see how it works, feel free to fill out this form, and I’ll get immediately back to you with a responsive auto-responder, attached workflow and all!

Richard

 In a recent article on the Dynamics CRM Team Blog, Ben Vollmer outlined an approach for assigning Leads on a “round-robin” basis, first one to rep a, second to rep b, etc. I’d been asked about this a few times so I was glad to see Ben’s excellent solution. When I tried to implement it, however, I found it a little complicated and realized I didn’t fully understand it. And when I don’t fully understand something, I always flatter myself by concluding that it’s a complex thing and that other people might not understand it either.

So my contribution is a slightly more detailed explanation of a slightly different approach. Judging from some of the comments and questions re. the original article, plenty of people are interested in this approach to record assignment, and not just for Lead records. And in Case you’re wondering, it works just as well for Case as it does for Lead!  I’ll cover how to do the Lead assignment version first, and at the end of the article show you how it would work for the Case entity.

First, Create a Custom “Counter” Entity

Follow these steps to create and configure the custom entity:

1. Create a new entity, called Lead Assignment Counter. You can accept all the defaults when you create this custom entity, although as you’ll see there’s no real reason to turn on support for Notes and Activities.

2. Create one custom attribute for this entity and name it “Counter”. It should have a Type of “int”, for integer. You can give it a minimum value of 0 or 1 if you like but that’s not required.

3. Create a new 1:N relationship from Lead Assignment Counter to Lead, by clicking the 1:N Relationships button, then New. Configure the relationship as I show in the following figure, by selecting Lead in the Related Entity pull-down list.

 
4. Save and close the Relationship window, then click on the Information tab for the custom entity and select “Settings” in the “Areas that display this entity” section.

5. Save and close the custom entity window, and then publish the Lead Assignment Counter entity.

6. Finally, refresh the browser window if necessary, and navigate to the Settings area, where you should see the new entity. Click the New button to add one record. In the example here, I kept the default settings for the “Name” attribute. This is obviously not required, but to make a point I entered a short note in that field, and “seeded” the Counter field with a starting value:

Now, Build the Workflow to Assign Lead Records

Once the Lead Assignment Counter entity is created, I’m ready to create the Lead Assignment workflow.

1. Create a new workflow on the Lead entity with an appropriate name, give it a Scope of Organization, and have it run automatically when a new record is created:

2. The workflow itself will consist of two parts. The first part is a single Update Action that will use the 1:N relationship I created from Lead Assignment Counter  to Lead. Effectively, every Lead record will be a child record of the single Lead Assignment Counter record. Remember the primary entity for this workflow is Lead, but the Lead entity is a child entity in this particular 1:N relationship. This way we will have access to the Counter field in the parent entity, and can use it to keep track of whose turn it is to get the Lead assignment! The first part updates the Lead record, so pull down the Add Step menu and select Update Record, to make it look like this:

3.Then click Set Properties, and navigate to the Additional Fields tab. The “Assignment Counter” lookup field should be there.  This is the Display Name of the 1:N relationship created previously. And in this case since there’s only going to be one record on the parent entity, you can simply use the lookup field to associate the Lead record with the record from the parent entity, as the next figure shows. Click Save and Close after selecting this.

 
4.The second part of the workflow is a series of conditional branches, one for each of the sales reps who will be getting the lead assignments. Each branch uses a Check Condition to see what the current value of the Counter field is. If it’s current “1”, the assignment in this example goes to Amy; if it’s “2”, it goes to Andreas, and so forth, as you see here:

5. After each Assign action, the next action will be an Update Record. We need to reach back up into the parent record we use for counting and increment the Counter field, as you see in the next figure. An alternative approach would be to “hardwire” each of these steps, with the first one setting the value to 2, the next step setting it to 3 and so forth. On the whole I prefer the approach we show here, since it makes it a little easier to keep track of things if you need to add or remove sales reps or make other changes.
 

6. The only conditional branch that’s different is the last one. On the last one you need to reset the counter value to 1, so the next record that gets created essentially starts the process over again. 

After saving and publishing the workflow, you can test it by adding a few Lead records. In the next figure you can see some test data that illustrate how it might work.

Generalize the Approach to other Entities

As I mentioned above, you can use this for assigning other record types also. Basically, anything that can assigned in a workflow, and that can be on the child side of a 1:N relationship, can take advantage of this round-robin assignment technique. Here’s what it might look like for Case:

If you’re a frequent reader of the Trick Bag you may have noticed a recent spate of articles about Dynamics CRM workflows. Most of these and many more to come are examples taken from a book I published on www.Lulu.com (If you aren’t familiar with lulu, it’s a “self-publishing” site where you can publish pretty much anything you want. It’s pretty cool, and takes a lot of the work out of publishing. Except for the part about creating the content!)

Dynamics CRM 4.0 workflows are a big topic for me, so much so that I published the aforementioned book. Here’s a link to my Lulu Storefront, which I should warn you is totally not fancy. Anyway, I’m hard at work on a new and improved version of the book, with more topics covered, more examples, and real book stuff like a TOC and an index.

Of course I don’t want to discourage you from buying the current version, so if you do, I’ll email you the new one when I finish it. I’m shooting for early May.   

So, if you ever see the following Lulu widget on these pages in reference to “Workflow in Microsoft Dynamics CRM 4.0″, feel free to …

Assigning Records Using Queues?

As all well educated CRMers know, only a limited number of record types in Dynamics CRM (Cases and Activity records, to be precise) can be assigned to  a Queue. When a user “accepts” a record from a queue, the record is assigned to that user. We can refer to this as assigning on a “first-come first-served” basis, since whoever accepts the record first gets it. Using an approach I will outline here, we can use queues to assign Lead records in this way…even though Lead records themselves — along with every other record in CRM other than Activity and Case records — cannot be assigned to a queue!

Setting Up and Building the Workflow

I wrote this workflow using the downloadable public CRM 4.0 VPC image. To build it by following the steps provided, you need to do a little setup first:

1. Create a business unit called “Sales” under the root business unit, adding Amy Alberts to that business unit and assigning her the security role of Sales Manager.
2. Add a few more users to the Sales business unit you can use for testing, assigning them to the Salesperson security role.
3. In order to get this to work right you’ll need to slightly modify the Salesperson security role, but I’ll tell you how to do that at the end of the article.   

We will use an automatic workflow that runs when a new Lead record is created. It will create a Task record and assign it to a queue. A user will be able to see the new Task record in the queue, and will be instructed to accept and complete the task in order to “claim” the new Lead. The workflow will wait until the task is completed, and then assign the Lead record to whichever user completed the task. This is actually a general technique and can be used to assign ANY record in Dynamics CRM, but we will use the Lead entity to illustrate. Here’s how to do it:

Start by creating a queue appropriate for this process. Navigate to the Business Management tab in Settings, click Queues, and click New from the Queues grid. We will call our new queue “Open Leads”, and assign it to the root business unit.

Once the queue is created, follow these steps to create the workflow:

1. Create a new workflow on the Lead entity with an appropriate name, scope it at the Organization level, and have it run automatically on the “Record is created” trigger. You can see these in the Workflow Properties section here:

2. The first action in the workflow will be Create Task. Click Set Properties on the Create: Task line to open the Create Task dialog, which you can see in the next figure.  The Regarding field will already be filled in with the Lead. We used Dynamic Values to pop the Lead Topic onto the end of the Subject line, but that’s optional.

Notice that this workflow makes “Amy Alberts” the Owner of the task. In the CRM organization this was created for, she is assigned to the Sales business unit, and has a security role of Sales Manager. We could leave the Owner field empty here, but that would cause other problems we will discuss below. The reason the Owner field is not required in automatic workflows like this one is that the workflow runs in the security context of the workflow’s owner. Since this workflow is owned by the system administrator, any record it creates that does not have a different user specified as the owner will be owned by the administrator.

3. After the Task record is created, the next action in the workflow is to “assign” that Task record to the Open Leads queue. Remember, assigning to a queue doesn’t change the owner of the task. (I always put “assign” in quotation marks to remind myself so I don’t forget!) On this step you don’t need to use Dynamic Properties since you can simply enter the name of the queue onto the lookup field you can see back in the screenshot in step 1.
 

4. After putting the Task record into the queue, add a Wait condition. The workflow will wait until the Owner of the Task record changes – which will happen when any user other than Amy the Sales Manager accepts the Task record from the queue. The next figure shows how you can specify that Wait Condition. Notice you need to identify the Task in the “Local Values” section of the drop-down menu. Any record that a workflow creates will be available in Local Values, and once you select it you can access its attributes – in this example, to specify the condition the workflow will wait for.
 

5. After specifying this condition, save, close and publish the workflow to see how it works.

Queues, Record Assignment, Security Roles and Workflows

This workflow raises some interesting issues regarding queues, record assignment, security roles, and how they interact with workflows. Basically, any user who will accept one of these tasks to get the lead assigned to them must have sufficient Assign privilege on the Activity entity. The standard Salesperson security role only has User-level Assign privilege on Activity (along with most of the other core records, including Lead). What this means is that by default, a user assigned to the Salesperson security role will not be able to accept activity records from a queue (such as the Task record we used in this example).
Suppose that we had not specified the Sales Manager as the owner of the task record created in the workflow as we discussed above. In that case the task would be owned by the system administrator, who is assigned to the root business unit. If a user assigned to the Sales business unit with a Salesperson security role attempts to accept the task from the queue, he or she would see this rather dramatic error message:

This is why we assigned the new Lead records to the Sales Manager, who is in the same business unit as the Salesperson(s). We then needed to make one change to the Salesperson security role: elevate the Assign privilege on Activity from User to Business Unit. We highlight this in the next figure.

After making this change, a Salesperson in the same business unit as the user to whom the activity has been assigned (Sales Manager Amy, in our example) can accept the task record from the queue successfully. You might think they also need Business Unit level Assign for Lead, but they don’t. This is because it’s the workflow that does the assigning of the Lead record, and the workflow runs in the security context of the owner of the workflow! Since the user has to manually accept the Task record from the queue that happens in their security context and they need these slightly higher privileges on the Activity entity.

I know — not a very sexy title, but this can be a confusing issue, and it has plenty of applications if you need to create automatic workflows in CRM. The basic issue is this: if you have an automatic workflow that should only run for SOME users but not all users, how do you do that?  

Consider the following business requirements:

Your organization will make extensive use of service cases, and will use the Case entity to track them. Most users throughout the organization will be able to create a Case record (in CRM security-speak, they will have Create privilege on the Case entity), but when a Customer Service Representative opens a Case for a customer, an automatic workflow implementing an official service level agreement will run. A user in another department can create Case records for their own purposes, but the automatic SLA workflow should not run when anybody other than a CSR opens a Case.

Using the public VPC image for Dynamics CRM 4.0, we will create two child business units (Service and Sales) underneath the root business unit (MicrosoftCRM):

We will have some users assigned to each of these business units, as you can see here:

We have a workflow that will implement our official “SLA”, which we can see in the All Workflows view here:

Notice here that the “Standard SLA” workflow is owned by Paul West. Paul is playing the role of Customer Service Manager, but the important thing is that he is assigned to the Service business unit. Since he’s in that business unit, that is also the “Owning Business Unit” of the workflow. Here’s how the properties of the Standard SLA workflow are configured:

This workflow is scoped at the “Business Unit” level, and it runs automatically, whenever a new Case record is created. So, whenever any user in the Service business unit creates a Case record, the Standard SLA workflow will fire. Whenever any user in any other business unit creates a Case record, nothing will happen.

So this is all set up to solve the business problem outlined above, but here’s the catch: only the Owner of a workflow can publish the workflow! So unless Paul West (in this example), is a very technical Customer Service Manager, somebody else is going to have to create the workflow for him. Suppose that the user creating the workflow is a System Administrator, associated with the root business unit. This is a very typical configuration in many CRM organizations. The System Administrator can create the workflow, but if he publishes it, it won’t run for customer service reps, because the administrator is in the root business unit! And if the administrtor assigns it to Paul West, the administrator can’t publish it – because, like I said, you can only publish a workflow you own!

There are a couple different approaches to this, but on the whole, I think the best one is to assign the workflow to the most senior manager (user) in the business unit you want the workflow to run automatically for, and instruct that person how to publish it. (An alternative would be to move the administrator to that business unit, but that would probably cause more problems than it would solve!)

In any case, once Paul publishes the workflow, you get the results you want. Suppose Angela creates a new case. The workflow will run automatically, as she could see by clicking the Workflows link on the Case left-navigation as you see here:

But if anybody outside the Service business unit creates a Case record, nothing happens, just as it shouldn’t. (in terms of the workflow, anyway). Again, this takes a little getting used to especially if you’re in the habit of thinking that System Administrators can “do anything”. They can’t publish somebody else’s workflow, and they can’t trigger automatic workflows owned by somebody in a different business unit, as is illustrated by the following screenshot of a Case record created by the administrator:

Processes are to workflows what quarterbacks are to football: they get all the glory. And in Dynamics CRM, it’s often entities like Opportunities and Cases that will have complex multi-stage business processes implemented as a workflow.
 
But workflows can provide yeomanlike, behind the scenes functionality as well, such as bulk data updates where you need to update certain fields depending on the existing value of other fields, or where you need to copy data from existing rows in one entity to new rows in another.
 
Another example of this utilitarian type of workflow is when you want to streamline data entry for new records. This will really work for any entity in Dynamics CRM, but the example I go through in this new video I just posted has to do with the Account entity.
 
The example has some interesting characteristics:

• Updates the Territory value based on what the user enters for zip/postal code
• Illustrates a good use of Stages in CRM 4 workflows, to organize your workflows and make them more readable
• Illustrates conditional processing based on the Account Category value selected. In particular, it shows how you can use a CRM Queue to assign accounts on a first-come first-served basis, even though you cannot assign accounts to queues in CRM.

Anyway, here you go: Account Setup workflow recording.

I hope you find it useful…and if you do, it’s taken from our Building Workflows SkillPack, a subscription to which gets you the book I wrote on workflows, and access to the online site where you get content updates, full recorded content, plus monthly live Q&A sessions with me. And who wouldn’t want that!