Microsoft Gold Cloud CRM and Gold Cloud Platform Partner

I am proud to release Celedon’s AutoNumber Solution for Dynamics CRM to the Open Source community!

What it does
Basic Example
Extended Example
Complex Example
Conclusion
Download

What it does:

There are plenty of other AutoNumber Solutions out there right now. However most of the existing open source solutions are either out of date, no longer supported, or limited in features. Our solution is unique in that it is both open source and fully featured. In fact, it includes several very interesting and powerful features that even most of the paid solutions don’t have.

This solution has all the things you would expect to see in an AutoNumber solution, such as fully-configurable numbers, custom prefix/suffix, guaranteed unique numbers, and so on. The two most significant features that make our solution different from others are:

  1. The ability to generate numbers conditionally, and
  2. A very powerful runtime parameter engine.

Our conditional number generation allows you to choose an optionset value which an autonumber will apply to. This means numbers will only be generated for new records matching those selected for autonumber. The runtime parameters have many features that are fully described on the Readme page on GitHub and you will see that our solution goes above and beyond what is normally expected. For example, we provide the ability to insert attribute values while also enabling custom formatting on those values. Additionally, our engine also provides an IF-ELSEIF-ELSE syntax that lets you insert predefined values using other attributes as the conditional parameters. This combination of features creates what is probably the most powerful AutoNumber solution currently available.

Basic Example:

Imagine a scenario: we are using the Account entity to track Customers, Vendors, Partners, Competitors, maybe more and an optionset determines the account type for each record. Let’s say you only want to assign autonumbers to Vendor and Customer accounts, but not to any other account type.  With our AutoNumber solution, you can easily implement this scenario with following steps: Create a new autonumber record for the Account entity, make it conditional based on the optionset value for Customer type, and set the prefix as CUS-. Then create a second autonumber record for the Account entity, make it conditional based on the optionset value for Vendor type, and set the prefix as VEN-.  And that’s it!
null
null

With these settings in place, all new accounts created as customers will get a number such as CUS-0001, and all new accounts created as vendors will get VEN-001. The two number sequences will remain separate for those two types, and all other account types will have no auto-generated numbers unless you provide additional autonumber settings for them.

Extended Example

Our first scenario is actually demonstrating the conditional optionset features but we are not using any runtime parameters. So let’s take it a step further: Starting with the same example scenario as above, let’s say that we want the Customer numbers to be suffixed with the year the Customer was created. And we also want Vendor numbers to include the State/Province abbreviation taken from their location information.
The solution is simple: Edit the Customer autonumber and add this as the suffix: -{createdon:yyyy}. This formatting string will instruct our autonumber engine to include the Customer’s createdon attribute value, formatting with the 4-digit year only. Next, we edit the Vendor autonumber settings to include the following as the suffix: {address1_stateorprovince}.


From now on, all your new customer numbers will look like this: CUS-0002-2015, CUS-0003-2014, CUS0199-2016, and so on. And all of your vendor numbers will look like this: VEN-0002TX, VEN0003WA, etc.

Neat huh?

But wait, there’s more!

Complex Example

In above example, we’re using the address1_stateorprovince attribute to get the state abbreviation to use in the vendor numbers. As you know, this is just a text field and barring any custom validation, users can enter anything into the field, which means it’s actually not a reliable field for an autonumber generation. To avoid issues with invalid or null data, our solution supports Lookup attributes and OptionSet attributes as parameters. In fact, we support all attribute types, but in this example, a lookup or optionset is the way to go. A common customization we see in Dynamics CRM deployments is a custom State/Province attribute, it could be either a lookup or optionset depending on the use-case. In the case of a lookup or optionset attribute being specified as a parameter, the runtime will retrieve the display name or label of the selected value, and that will be inserted into the autonumber. So if we encounter either of these scenarios, all we have to do is use the name of the attribute as your parameter: {new_stateabbreviation}, and that’s it! So in this example, if the new_stateabbreviation attribute is an optionset, then the optionset display label will be retrieved and if the attribute is a lookup, the primary field (such as new_name) will be retrieved as the suffix value in the new auto number.

I’ll take this example just one step further:
Using the same scenario again, but this time let’s say that we have a lookup to choose the State instead of an optionset. But the display name on the entity is actually the full long name of the State and the abbreviation is another custom field on the lookup. The same parameter won’t work because we don’t want to see the full long name of the State in the autonumber. Our solution supports that scenario as well with a slight modification to the attribute: {new_state.new_stateabbreviation}.  In this parameter “new_state” is the name of the lookup attribute to the related State entity, and new_stateabbreviation is the attribute on the related entity that contains the value we want to insert into the autonumber.

Conclusion

These are some pretty basic example scenarios which don’t begin to take advantage of the full power of our solution’s runtime parameter engine. If you are interested to know more about the runtime engine’s extensive capabilities, it is all described in the Readme. I will do a part 2 of this post another day that describes some of the more powerful features of this solution.

If you have any questions/comments let me know in the comments below. If you have any interesting use-case scenarios that this solution solves for you, I would love to know, please share it below.

Download Links

Source Code
Latest Release