Everybody wants six-pack abs, but you have to do a lot of crunches to get them. And alas, the Body by Jake Ab Machine is no longer on the market. Flabby, unsightly (Dynamics CRM) data are significantly easier to tighten up, and if you follow the simple 3-step program I describe here, your data will be the envy of everybody at the next Dynamics CRM User Group meeting!

In a more serious vein, I think the approach I describe here really can help improve your data quality, and the requirements that drive it are in my experience pretty commonplace. It will help you if

1. you want all of your contact records to be associated with a parent account; and
2. a significant chunk of your contact records are converted from lead records.

Here’s my three-step program guaranteed to get you that perfect data you’ve always wanted:

1. Customize the Contact entity, by making the Parent Account lookup field required.
2. Customize the Lead entity, by adding a lookup field allowing users to tie a lead record to an existing account.
3. Make a workflow that runs when a new contact record is created, checks to see if it originated from a lead, and if so, associates it with the appropriate parent account.

“Out of the Box” Dynamics CRM Lead Conversion

I’ll provide detailed instructions in a minute, but first I’ll provide some background on an important and often misunderstood piece of this: the lead conversion process. In out of the box, un-customized Dynamics CRM, leads are essentially standalone records – they aren’t associated with any other records (such as a parent account), and no other records (e.g., opportunities, invoices, cases…) are associated with them. For example, here’s a pretty-much out of the box lead form:

Notice that not the Topic, Last Name and Company fields are required. Many people don’t like the fact that the text field “Company Name” is required, since users are forced to enter a free-form text field for what may already be an existing account. (One of the customizations I describe below will fix this.) After you save a lead record there’s a Convert button you can click, and if you do, you’ll see that you can convert a lead record into one or more of three different record types: Account, Contact, Opportunity:

Most of the information you’ve entered about the lead (basic information on the lead form, a history of your activities) gets carried over to the records you create during the conversion, which is why you’d go to the trouble of converting in the first place. But since there are lots of permutations of the different records you can create with those three checkboxes, here’s a summary:

It’s the last of these that can get confusing. You can see it if you try to convert a lead to an opportunity and notice you can’t click OK unless at least one other field is filled in: you either have to also convert at least one of the other two convertible records (account or contact)…or you have to select an existing account or contact from the “Potential Customer” lookup field. One potential glitch I’ve noticed is that you can actually select an existing customer to attach the converted opportunity record to, and after doing that, click one of the other two options (or both!):

Yikes! It turns out that if you do this, Dynamics CRM ignores the Potential Customer lookup, and performs the steps described in the last row of the table above.

Besides being confusing, I think the main problem with this out of the box lead conversion process is that it requires you to enter a free-form text field for Company Name that has no tie to any existing account records. All too often, one of these two things happens when a sales rep creates an opportunity record by converting a lead:

• Since they’ve provided a company name on the lead form (they didn’t have any choice, after all), they simply use the account checkbox on the Convert Lead dialog (after all, they’ve already supplied the company name)…and if it’s an existing account, they create a duplicate record.
• They forget to select an account record from the Potential Customer lookup and just select the Opportunity and Contact check boxes. Again, the new opportunity record won’t be attached to the correct account, plus in this case you’ll have a standalone contact record created.

Effectively, this lead conversion process encourages users to enter bad data, by requiring that free-form “Company Name” field on the lead form. If you get a significant number of leads that are in fact contact records at existing accounts (say, collecting business cards at a trade show), this can lead to poor data quality and frustrated sales reps.

Three-Step Summer Workout Program to Whip Your Data into Shape

Try something along these lines:

1. Customize the Contact entity. If you really want all contact records attached to a parent account, change the Requirement Level to “Business Required” for the paretcustomerid attribute (Display Name “Parent Customer”). It’s not required out of the box, but it’s easy to make it required. Open the Contact entity for customization, click Attributes, locate the Parent Customer attribute, and make the change shown in the following screen shot, then save and publish the customization.

   

    

2. Customize the Lead entity. This involves just a little bit more customization. Here are the two most important:
   1. Add a custom N:1 relationship from Lead to Account, and add the lookup field created by Dynamics CRM to the lead form. Give it a display name of “Existing Account”, to make it obvious to your users what it’s for.
   2. Change the requirement level of the companyname attribute (display name “Company Name”) to “No Constraint”, and change its display name to “New Account”, to make sure users only use this free-form text field if they don’t think the account exists.

   After you save and publish those changes, you can make your customized Lead form look something like this:

   

3. Finally, create a workflow that runs automatically when a new contact record is created. (The one I show below is written for the Contact entity, has a Scope of Organization, and runs automatically on the “Record is created” trigger.) It will have logic like this:
   1. Check to see if the new contact record is a converted lead record. (The Contact entity has a sweet attribute – “Originating Lead” – that is designed for this purpose!)
      1. If it is a converted lead record, check to see if the “Existing Account” lookup was filled in. If it was, then the workflow should update the new Contact record by filling in its Parent Customer lookup field with the value of “Existing Account” from the lead record.

   Here’s a screen shot of my workflow’s Step Editor, in its unpublished state:

   

    

After you publish this workflow, create and convert a few lead records to see how it works. By requiring contact records to have parent customers, and by allowing your users to associate lead records with parent customers early on in the sales process, you’ll have happier, more productive sales reps, and your data quality will be the talk of the CRM neighborhood.

If you found this helpful, my book on Building Workflows in Dynamics CRM 4.0 has detailed explanations of topics like this one plus lots of others, and downloadable versions of the example workflows. Here’s a link to the page on Lulu.com where you can find out more and buy the book. 

Cheers – Richard Knudson, richardk@imginc.com

When to Wait, When to Timeout?

When it comes to workflows in Dynamics CRM, timing isn’t the only thing that matters, but it’s definitely up there. In the 4.0 release we have lots of flexibility in this area, and I know from the questions I often get (not to mention my own learning experience!) how confusing it can be to keep the different options all straight. In particular, the “Wait” and “Timeout” conditions are both important ways of pausing a work process, and they seem similar, at least at first. As it turns out, they serve quite different functions, and I’ll try to clarify them here with a brief explanation and a couple examples:

Use Wait when you want a work process to pause until a condition changes. Some common examples of the kinds of conditions you might Wait for include:

• Wait until an assigned task is completed
• Wait until the status or status reason of a record changes
• Wait until the value of an attribute in a related entity changes

Use Timeout when you want a work process to pause until a specified date, for a specified period of time, or until you reach a date relative to the value of a CRM record’s date field. Some examples of these include:

• Timeout until an Opportunity record is “overdue” (the current date is greater than the opportunity’s estimated close date)
• Timeout until September 1, 2009 (maybe there’s a conference coming up on September 8 and you want to send a one-week reminder email to attendees)
• Timeout until one week has passed since a new Account record was created

In Dynamics CRM-speak, we can say that a Wait condition will be met when the attribute value of some entity changes. On the other hand, a Timeout condition will be met when time passes: either clock time or time relative to the value of a date attribute of some entity. My little mnemonic to help me remember is that of the two conditions, only Timeout contains the word “time”. Clever, eh?

Using a Wait in a Workflow

Here’s an example of a Wait condition: a simple sales process might have stages, and one or more stages might assign tasks. There’s nothing about creating and assigning a task record in Dynamics CRM that makes a workflow pause, so if you want to make sure the task gets completed before going on, you can add a condition, to the effect “Wait until activity status=completed”. The following screenshot shows a simple sales process implemented as a workflow on the Opportunity entity. It starts automatically, when a new opportunity is created, and has these characteristic Wait until conditions in each of the first two stages of the sales process:

Using a Timeout in a Workflow

I understood Waits before I understood Timeouts – probably because the latter are a little harder to find! One of my favorite examples of using a Timeout in a workflow is another aspect of a sales process: making sure that opportunities don’t go past their estimated close date (or at least, if they do, make sure you take appropriate action!). Here’s a simple implementation of that logic, in an automatic opportunity workflow that starts by timing out until one day before the “Est. Close Date” of the opportunity and sends a reminder email. Next, it times out until seven days after the opportunity was supposed to close…and closes it out if it is. (Implementing a process like this might be a culture shock for some sales organizations, so you might want to warn them in the reminder email that this will happen.)

If you clicked on the second of these two Timeout conditions, here’s what the condition looks like:

Like I said, this is pretty well hid! In order to add the Timeout condition, you first have to select Wait Condition from the Add Step menu, and only when you open the Specify Workflow Condition dialog do you actually configure the Timeout! Within the Specify Workflow Condition dialog you do this by selecting the somewhat cryptic “Workflow” value from the first column’s drop-down menu, and then selecting Timeout in the second column, as the previous screenshot illustrates. After selecting Timeout, you’ll see that “Equals” is your only option in the third column, and then you use the Form Assistant to configure the Timeout. In the example I show here I followed these steps to configure the condition:

1. selected “7″ in the Days field
2. selected “After” in the next field
3. selected the Opportunity entity in the Look for pull-down
4. selected “Est. Close Date” as the field to make the Timeout condition evaluate

This takes a little getting used to, but after you do it a few times you get the hang of it.

(In my opinion, this would be easier to understand if you could select either Wait Condition or Timeout Condition from the Add Step menu directly, but then I didn’t design the CRM 4.0 workflow design UI.)

If you found this helpful, my book on Building Workflows in Dynamics CRM 4.0 has detailed explanations of topics like this one plus lots of others, and downloadable versions of the example workflows. Here’s a link to the page on Lulu.com where you can find out more and buy the book. 

Cheers – Richard Knudson, richardk@imginc.com

Go together like cold Negra Modelo and fresh Guacamole!

I recently visited Mexico City, and had the good fortune to stay in a hotel (the Fiesta Inn, in case you ever visit the Santa Fe district) that served the best guacamole I’ve ever tasted. It was even better if consumed with a couple cold Negra Modelos. As I enjoyed that particular combination, I also learned to enjoy another one: the Dynamics CRM 4.0 Data Migration Manager and automatic workflows to configure the account records I was migrating.

I recorded a video on the topic (the DMM and account configuration workflows, that is), and if you’d like to simply jump in and watch it, here’s the link:

Using the Data Migration Manager and Automatically Configuring Account Records

Background

Until recently, I’d had limited experience with the Dynamics CRM 4.0 Data Migration Manager (henceforth, DMM). Mainly I’d used it to migrate the sample data set you can download here. You’d expect it to work well with a sample data set designed for the purpose, and it does. A few weeks back I needed to use it for a real customer engagement…so I finally had to actually learn it. My impression from a recent meeting of the Dynamics CRM User Group is that not many people are using it, perhaps assuming that tools like the ones offered by Scribe Software are a practical requirement to migrate real data. I might have thought that before I learned how to use it but I don’t anymore. If you need to migrate data into Dynamics CRM 4 I encourage you to consider the DMM. Certainly it has the advantage of being free, and while there are plenty of things Scribe can do that the DMM cannot (e.g., real-time data integration applications), my guess is that for a wide class of data migration scenarios the DMM will do just fine.

Dynamics CRM 4.0 Data Migration Manager

The DMM is a standalone application. You run it on a PC with an Internet connection (or at least, with a connection to your CRM server), and you must be a system administrator to run it. It’s worthwhile comparing it to the Import Data Wizard, which is exposed from within the CRM interface, and can be used by any CRM user with sufficient permissions. Here’s a quick summary of the things the DMM can do that the Import Wizard cannot:

These five features are important, and with the exception of the last one (which is a nice-to-have but maybe not a must), come pretty close to defining a baseline required feature set for an enterprise-capable data migration tool.

Here are the features I illustrate in the video:

• Migrate a complex, relational data set. I show a data migration of Accounts, Contacts and activity (phone call) records. These are related to each other, and as you’ll see if you watch the video, the DMM is excellent at migrating complex data sets like this.
• Maintain actual historical values of “created date” for migrated records. Unless you want to lose the dates records were created, this is a must-have feature, and the DMM handles it nicely.
• Can create custom entities on the fly. As I said above, this might not be a must-have feature, but it sure is convenient!

 In some other videos I’ll focus more on some of the other important features.

Account Configuration Workflows

OK, what does any of this have to do with account configuration workflows? Well, strictly speaking, not much. But just as my favorite guacamole is better with Negra Modelo, my argument is that the DMM is better with one of these. The key thing is that if you have a published workflow triggered by “create record” for account (any entity, for that matter, but these are generally more valuable for account records), it doesn’t matter how a record is created – the workflow will always run.

In the example I show, the imported account records have values for the country they’re located in, and the U.S. records contain zip codes. I’ve got territories defined (using the out of the box CRM Territory entity) of these values: International, East, Central, West. My organization’s base currency is the U.S. dollar, and I’ve got additional currencies (Mexican Peso, Canadian dollar, and the Euro). Here’s the heuristic structure and logic of the workflow:

• First, update any information that should be shared by all account records
• Next, check to see if country=US
  • If so, check zip code value
    • If starts with 1,2,3 or 4, set Territory=”East”
    • If starts with 5 or 6, set Territory=”Central”
    • If starts with 7,8 or 9, set Territory=”West”
• If country value <> US
  • Set Territory=”International”
  • Check country value
    • If MX, set default currency = Peso
    • If CA, set default currency = Canadian dollar
    • If GE, FR, EN, set default currency = Euro

As I said, it’s a relatively simple workflow, but it improves my account data a lot! After migrating the data, in the video I show how easy it is to create a graphical view of how your data are distributed across various categories. I show a pie chart of how my new accounts are distributed across territories, but I could just as easily do it for countries, currencies, or any other piece of data stored on the account records.

For more information…

At the Dynamics CRM User Group Meeting on June 25^th, 2009, I’m going to give a more thorough presentation on the topic of the Data Migration Manager, so if you’re interested, please join us: register here.

Also: I’ve got a whole book on workflows, chock-full of examples, explanations, and tips & tricks. It’s available in print, downloadable, and even a cool new e-Book version for you Kindle readers. You can buy it from my lulu.com storefront, at http://stores.lulu.com/richardknudson 

Or if you prefer, you can get it on Amazon for the same price.

Cheers -

Richard – richardk@imginc.com

It’s not always Opportunities that Drive the Sales Process

Business processes come in as many varieties as there are businesses, and in Dynamics CRM this is amply illustrated by the rich variety of workflows organizations implement to drive the sales process. Many of these sales process workflows are created for the Opportunity entity. This is appropriate, since it represents a “potential sale”, and when an opportunity gets closed out with a status of “Won”, well…that’s a closed sale. An entire sales process might be built entirely around opportunities: tasks get assigned, approvals are required, proposals get delivered. One characteristic implementation uses workflow “stages” to represent the stages of a sales process, and to assign various tasks (create a proposal, meet with the client…) in each stage. A workflow can be made to wait in a stage until required tasks are completed, and a sales pipeline report might the total potential revenue across all the open opportunities in the various sales stages.

But while the Opportunity entity is important, it’s only one of several convenient out of the box entities you can use to build your overall sales process. The others, more or less in order of how they fit into the Dynamics CRM pipeline, are:

• Quote. If you have a formal process for presenting a quote, proposal, bid or whatever you call it, that’s what the “Quote” entity’s for in Dynamics CRM.
• Order. If you need to alert the production or shipping crew when a sale is made, you can use the “Order” entity for that. If you’re fully bought in to the CRM pipeline, you can have CRM create the Order record automatically when a customer accepts one of those quote records.
• Invoice. Need a record for accounting? Few organizations use CRM as an accounting system, but plenty of them use the “Invoice” entity in Dynamics CRM for historical reporting on sales, and some build ERP integrations, so accounting can maintain invoices in the system of record, and the sales team can still see everything in CRM.

It’s easy to get in the habit of thinking of a simplistic CRM sales process, like this:

Opportunity -> Quote -> Order -> Invoice

It’s not correct, however; the platform is actually much more flexible than that. I’ll show an example of a workflow here that makes quotes the center of the action. Quotes are good for scenarios like this: submit quote -> negotiate -> revise quote -> re-submit, etc. – and they give you the ability to track all of these negotiations and resubmissions.

Plus, quotes are part and parcel of the sales process: one can be automatically created from an opportunity record, and when it is, it’s a “child” record of the opportunity. The approach in this workflow will exploit that relationship: I’ll write the workflow for the Quote entity; it will check to see if the quote is related to an opportunity, and if it is, the workflow will update the parent opportunity record so we will always have an accurate pipeline for reporting services.

How it Works

This workflow requires one customization of the Opportunity entity: there’s a Sales Stage picklist attribute that I customized to have the following values:

• 1. Qualify Opportunity
• 2. Draft Quote
• 3. Active Quote

As I mentioned, the workflow is written on the Quote entity, and will run automatically when a new quote record is created and when the status of a quote record changes; it’s actually relatively simple. Here’s what it looks like:

Here are the most important points of the workflow:

• 1. Since quote records can be but are not required to be created from an opportunity, we start by checking whether or not this quote record has a parent opportunity.The Quote entity (like the Order and Invoice entities as well) has an attribute called “Opportunity” – that’s what this is for. I use the condition “If <something> contains data” all the time. In this case the <something> is this attribute, and the way I wrote this workflow, the rest of it will run if the condition is met (this quote is related to an opportunity), otherwise, not.
• 2. Next, I’ve got a conditional block that checks the status of the quote. Quotes start out in “draft” status, and what this workflow does in that case is update the (parent) opportunity record, setting the value of Sales Stage (described above) to the appropriate value.

 Here’s the key point: you can’t write this workflow on Opportunity, since parent records don’t know anything about child records in the context of a workflow. But child records know lots about parent records, so these Update Record actions can really make any changes to the parent opportunity record we need them to!  

Summary

This is a relatively simple workflow, but it illustrates a general point: if your sales process involves more than just the Opportunity entity, you need to write one (or more) workflows for the child entities Quote, Order and Invoice. For example, if you create an Order record when a Quote is accepted, you might need to also write an automatic workflow like this on Order. That might be slightly complicated by the possibility of the Opportunity being closed at that point: how can a workflow update a closed (won or lost) Opportunity record? But let’s take this one stage at a time and leave that problem for another day. And you can quote me on that.

And if you like this one…

I’ve got a whole book on workflows, chock-full of examples, explanations, and tips & tricks. It’s available in print, downloadable, and even a cool new e-Book version for you Kindle readers. You can buy it from my lulu.com storefront, at http://stores.lulu.com/richardknudson 

Or if you prefer, you can get it on Amazon for the same price.

Cheers -

Richard – richardk@imginc.com

Book Publishing Ain’t What It Used To Be

It’s a lot easier. I just published the Second Edition of my book, Building Workflows in Dynamics CRM 4.0. I used the “self-publishing” site, www.Lulu.com, and although I’m happy to report that the publishing part is a lot easier nowadays, the part about writing good content is as difficult as ever! I think my book turned out well, however, and I recommend you buy it and give me your feedback. In the rest of this article I’ll talk about why I wrote it and what I was going for, as well as a few tidbits about lulu.com I thought you might find interesting.

But if you want to go straight to the checkout counter, here you go:

Why I Wrote a Book on Dynamics CRM Workflows

It wouldn’t take more than a visit or two to my blog to realize I’m very interested in Dynamics CRM 4.0 workflows. I’ve been using, consulting and training on CRM 4 since before it came out, on CRM 3 before that, and I think the improvements to workflows are the single biggest area of improvement from the previous release to the current one.

As I was learning how to do workflows in CRM 4.0 I had to rely on a mish-mash of learning materials: blog posts, msdn articles, the CRM 4 SDK…and most of all, trial by error. There were no good books dedicated to the topic (or even bad ones, for that matter), so I had to take this brute force approach to learning it.

In my experience the brute force approach is often effective, but not very efficient, and my learning of Dynamics CRM 4 workflows was no exception to this rule. That is, I ended up learning the topic (very well, I think!), but it could have been done in a lot less time.

That’s why I wrote a book all about Dynamics CRM workflows: so you can learn more efficiently how to build, maintain and troubleshoot them.

Why I Published on www.Lulu.com

If you want to publish a book, www.Lulu.com is a good place to do it. It’s a self-publishing site, with all of the tools you’d expect to make the publishing process easier: a wizard to walk you through uploading your content, selecting from different printing options, creating your cover, and so forth. But what makes it more interesting is its online marketplace — not only can you publish your book there but you can market and sell it as well.

I published a first edition of my Building Workflows in Dynamics CRM 4.0 in October 2008, and just released a brand new and improved Second Edition.    

If you need to learn about Dynamics CRM 4.0 workflows, I recommend you purchase my book. Along with a book purchase, you get a free subscription to the online version of the book, which contains the downloadable (and frequently updated) content, plus all of the workflows so you can download them, import them into your CRM organization and modify them to suit your business requirements.   

How to Find it and Buy it

Here’s my “storefront” on lulu.com: http://stores.lulu.com/richardknudson

If you visit the storefront you’ll notice the book is even available in an “ebook” format! So in case you’re an avid Kindle reader, you can at long last curl up with a good digital workflow read.

Use a Custom Audit Entity and a Simple Workflow to Find Out

I’ve always liked lists: shopping lists, birthday gift lists, to-do lists, top ten American League hitters by different categories, you name it. One of my current favorite list types is the Dynamics CRM Marketing List. (I’m sure you wondered where I was going with that list thing!).

It took me a while to appreciate the value of marketing lists and to develop some good intuition about their strengths (and their limitations!). In this article I’ll provide some tips and tricks on how to get the most out of marketing lists, and show you how to use a custom entity and an audit workflow to keep track of how your lists change over time.

Marketing List Fact #1

Marketing lists have “members”, and those members are restricted to Account, Contact, and Lead records only. This is one of the primary limitations of marketing lists. From a practical standpoint, it means that if you want to take advantage of marketing lists you might have to “shoehorn” something that you might not regularly think of as one of these entities…into one of these entities.

Now unless you know the trick I’ll describe later, it might never occur to you to do this, but you can decide for yourself later on.

Marketing List Fact #2

Marketing lists are static. The way they work is, you build a query to select the list’s members from the underlying records in your account, contact or lead tables. After you add the members to your list you get a convenient “members count” value that tells you how many members there are. This is nice, by the way, since it’s not that easy to tell how many records you have. (Navigate to the standard contacts grid, and see if you can tell how many contacts you have. If you’ve got more than 250, there’s nothing built in to the standard UI to tell you!)

But the point is, once you add members to a marketing list, no matter what happens to the underlying data, the members count stays the same until you manually update it. For example, on a monthly basis I send out an email newsletter, and I use a marketing list of Contact records for the purpose. Every month before sending out the newsletter, I need to update the members of the marketing list to make sure I do things like this:

• Add new contacts who want to receive the email
• Delete contacts who may have opted out, or may no longer be active

Once you get used to the fact that marketing lists are static you appreciate why they’re that way…but first you need to realize it and make refreshing them part of your regular routine.

Marketing List Fact #3

As I mentioned previously, marketing lists have a “members count” field that tells you how many current members are in the list. If you’re interested in building your marketing lists over time, this is obviously an important number, and if you’re a marketing manager who is partly compensated by growing marketing lists, it’s a really important number. As you may know, there are no built-in audit capabilities for any Dynamics CRM records. There are some well-known techniques you can use to add auditing for records like accounts, opportunities, and so forth; here’s a link to an article I wrote on the topic.

What I’ll describe here is a way you can adapt that technique to the current challenge: how do you keep track of how your marketing lists change (hopefully, grow!) over time.

Once you understand the general approach to creating audit records, this version is simple:

1. Create a custom entity (I call mine “Marketing List Audit”) with a custom integer attribute called something like “Members Count”.

2. Create a 1:N relationship from Marketing List to the Marketing List Audit entity.

3. Create a workflow on the Marketing List entity that adds a related record to the Marketing List Audit entity. Update the audit record’s “Members Count” attribute with the current value of “Members Count” from the Marketing List.

That’s the basic technique. Here are a couple examples of how it can look when you’ve got this kind of auditing in place.

Here’s the view from the Marketing List, of all the associated audit records, the count and the date the audit record was created:

Here’s a part of a report, written using the CRM 4.0 Report Wizard – this is a good example of how a time series of data can look. You can see that the data points map to the audit records shown in the previous screen shot.

Implementing the Marketing List Audit Functionality

Just for fun, I’ll explain this functionality using screenshots of the workflow itself, starting off with one of the Administration tab.  Consider using the description field to make your workflows more self-documenting, like I show here:

The workflow is written against the Marketing List entity, and you can see in this example I expose it for On Demand use, and have it run automatically when attributes (members count) change:

It only does one thing: creates a new record for the Marketing List Audit entity. I use Dynamic Values to populate the name, relate it to the parent record, and fill in the value of the Member Count field:

That’s pretty much it!

One little security caveat

One thing to keep in mind: if you make a workflow like this available for On Demand use, another user might be able to run it. If they do, they need to have Write privilege on the Marketing List Audit entity. This is a common gotcha in these situations, since if you have it run automatically that is not the case. This can be a confusing issue, so here’s a quick summary:

• Workflows run On Demand run in the security context of the User who ran the workflow.
• Workflows run automatically run in the security context of the Owner of the workflow.

Since it tends to be System Administrator types who create automatic workflows, those workflows generally won’t have any problems running. In this example, since System Administrators have Write privilege on all entities (including custom ones), it will work. But if it’s exposed On Demand and the User running it doesn’t have Write privilege on the custom entity, it will fail with an ugly error message.  

Let me know if you have any questions, and I hope you find this useful! If you do, check out the brand new Second Edition of my workflows book, cleverly titled Building Dynamics CRM 4.0 Workflows, Second Edition. It’s got 150 pages of workflows like this one, and lots of others. If you purchase it, you also get a subscription to the online version of the book, where you can download all of the workflows from the book, plus more as I add them.