Saturday, February 8, 2014

Revisiting Workflows: Auto-Number

Back in 2010, I wrote how you can use workflows to create an auto-number counter for your records. Given the expanded functionality of workflows in CRM 2013, I thought it was a good time to revisit this solution to see if the new features make auto-numbering work even better.

Auto-Numbering Out of the Box

A little over three years ago, this is what we had in the, then beta, 2011 which was the same as what was available in version 4.


Today, we have a cleaner look but, functionally, auto-numbering has not changed one bit.


This is a shame but, thankfully we can overcome these shortcomings through workflows or, more commonly code. Codeplex also has a few options. Here is one I have used in the past with success.

Previous Workflow Problems

The biggest problem we had with workflows in previous versions of CRM was they were asynchronous. This meant they did not run straight away but got queued up and ran when the server decided (generally a few seconds later). This meant that, while we could build an auto-number tool with workflows, the number generated would not appear straight away and even if we closed and re-opened the form, if the workflow had not run, the number still would not appear.

With CRM 2013, we have synchronous workflows, which means they run straight away. We still need to refresh the form to see them but the new form behaviour of CRM 2013, this does not prove to be a problem.

The Structure

The structure for the counter is the same as the one from the previous blog (a new parent entity for Account holding a prefix and counter, and a workflow to make the magic happen). The main difference is we make the workflow run synchronously (by unselecting the ‘Run this workflow in the background’ tickbox).


In the previous version, I had trouble running the counter with one workflow but, this time it works fine and there are three steps:

  • Update Account (#1) – Linking the newly created Account record to the Counter record which defines the prefix and the current counter number value
  • Update Account (#2) – Modifies the Account Number field with the counter prefix and current counter value
  • Update Counter Record – Increments the current counter value by one

What We End Up With

The combination of a synchronous workflow and the form auto-refreshing on save means when hit the ‘New’ button, populate the fields and hit the Save button, our Account Number field is immediately populated; no reopening required.


One Last Improvement

One last thing you can do is make the Account Number field read-only. This can be achieved by going to the field properties on the form and ticking the read-only box.


or, for more exotic behaviour, you can use a Business Rule. In this example, we only lock the field once it is populated.



Asynchronous workflows, while easy to configure, always had shortcomings because you had to wait for them to complete. This meant, for the user, it was not always clear whether the workflow was happening and this had the potential to cause confusion.

With CRM 2013, we now have workflows which happen straight away and many of the previous ‘niggles’ have gone away. Combined with new features, such as Business Rules and the new Flow UI, processes are becoming more and more relevant for solving real-world business process problems, previously dealt with using jscripts and plugins.


Jukka Niiranen said...

Another important factor that sets the CRM 2013 real-time workflows apart from the asynchronous workflows is that they are executed as a part of the database transaction. In an auto-numbering scenario this can significantly reduce the risk of having duplicate numbers assigned to records, although the jury is still out on whether it's possible to generate a 100% unique number via workflow processes. Here's a post with some of my tests on such a scenario:

Leon Tribe said...


Great minds :) Your article also mentions the approach Shan uses which is really interesting and eliminates the need for the 1:N connection.