Autonumber in CRM – only with workflows

Almost on every organization I customize, there is a need for an autonumber in some shape or form. This could be for an account, opportunity, quotes, or some obscure custom entity. Nonetheless, this is not something Microsoft added OOB (exept for a very limited autonumber for case, quote etc.), which can’t really be modified.

This is my example on how to handle an autonumber in CRM, without any code, plugin or whatever… just with two custom entities and one workflow, for the base functionality.

Firstly, we need to create the 2 custom entities, which we will need for this to work. I call them AutoNumberDefinition and AutoNumberRequest. This is where all the magic happens. The Request entity is going to be a “hidden” entity, which is just going to be holding data for the autonumber creation. The auto number definition will be the UI of the solution.

The great thing about building this yourself is you can choose how complex you want it to be. Moreover, it is in the AutoNumberDefinition, where you define, how much complexity you want. Some of the basic information we want on this entity is an integer for the Last used number, a prefix, a postfix, different separators and selecting how many digits you want in your auto number.

The full flow looks something like this:

1. Create the desired Definition
2. Create a workflow to create a Request
3. When the request is created, the Inqury workflow transforms the data and updates the last number used, and create the values.
4. When the inqury workflow is done, the Request workflows updates the new number on the record.

This is an example of an autonumber I use:

This setup would make a number looking like this: PRE:001:POST. The workflow takes into account, if the pre or postfix contains data, and only inserts the separator of there is data in a given field. Before any of this works, we need to create a workflow, which will handle the information given. In the Request entity, we store the information needed for the display the autonumber on the records. I collect all the information needed here, and then I connect them in a calculated field. The reason I use a calculated field, is to avoid the thousand separator on numbers higher than 999. An integer like 10.500 gets its thousand separator removed when it is inside a calculated field.

The calculated field is fairly simple, as it just concats the values for the auto number.

The field called digit amount is a filler used, to make sure the auto number is showing as many digits as selected on the definition. I selected 3 digits, and the new number was only one digit, so it need to fill two 0’s in, for it to show 3 digits.

The workflow that controls the data, is a real-time workflow running OnCreate on the Auto Number Request, and it performs the following actions:

1. Increment the last number on the definition by 1
2. Looks for data in the prefix, postfix and separators, and copy the relevant data from the definition to the request form.
3. Update the Digit amount on the request, based on the last number used, and the amount of digits selected for the auto number.
   1. The workflow has an if-/else for each scenario of digit amounts (up to 6 digits).
      

The only thing we need now, is a trigger to create the request, which is a different workflow, running on the object needing the auto number. In my example, I am using Accounts. It is a real-time workflow I am creating to this, and it only requires 2 steps. To Create an Auto Number request and then Update the Account.

When this is all running, it looks something like this: