As the creator of the Auto Number Manager tool in XrmToolBox, I get two questions more than any other questions:
How can I number existing records?
How can I add dynamic content to the numbers?
In a previous article I gave my solution to the first question. I will now dive into the second one and show a simple way of adding dynamic information from the numbered entity and related entities into the numbered attribute.
Well, actually the trick here is to not use the numbered attribute as the numbered attribute.
Come again?
Since the auto number format does not support placeholders for dynamic data, we create a “plain number” attribute that gets the sequential part of the number.
Then we create another attribute that will be the numbered attribute to display, where we concatenate the sequential part with any dynamically retrieved information.
The dynamic part of the Rocket # attribute will be retrieved from a related entity defining the purpose of the rocket.
In this case, I will create a calculated field to compose the complete number for my Rockets. I want to compose my Rocket # values as a combination of the purpose code and the sequential number.
The calculation for my Rocket # attribute is then defined like this:
Concat(jr_purposeid.jr_code, "-", jr_seq)
When I create a new record, I get this result:
Side effects of calculated fields
My choice of using a calculated field as Rocket # has a few side effects.
Not stored
This may or may not matter, but the information is actually not stored on the Rocket record. It is evaluated each time the number shall be returned from the platform.
Not sortable
A secondary side effect of the number not actually being stored, is that you cannot sort by it in views.
Not persistent
Since the number is evaluated each time it is returned, it is not persistent. If you in my case change the code of a Rocket Purpose, the numbers will change accordingly. This may be both a pro and a con, depending on situation.
If you have read the book about Aniara, you know that what started as a “Manned Mars Mission” soon became a journey “To Infinity and Beyond”. If you have not, I strongly recommend you to read it. It is a fantastic sci-fi space odyssey from 1958 by Swedish author Harry Martinsson.
Overcoming the side effects
The side effects described above are all actually related to the use of Calculated Fields. You might just as well use synchronous (or even asynchronous) workflows to compose the Rocket # values.
The downside with that solution is that it will add an extra update to the transaction, as they cannot be performed before the new record is sent to the database for creation.
Next level
The next level of this approach is to have separate sequential series for the different Rocket Purposes, so rockets are numbered individually based on purpose.
In the next article, I will address that challenge…
Stay tuned!
Next article has arrived!
Conditional Unique Auto Number Sequences in Microsoft Dynamics 365 / CRM
Hi Jonas,
Have you put together much of that next article on having a separate sequential series yet? I’d be very interested in hearing your thoughts on how to handle that.
Thanks,
Jeff
Sorry, it’s still only in my head… ?
But no rocket science. Basically create one (hidden) autonumbered field for each “sequence” (probably related to some optionset) and have a visible numbered field that is composed out of the one valid numbered field.
Make sure invalid (based on selected option) is not numbered (which would create gaps in the sequence) by having realtime wf or business rule populate the invalid ones with any dummy text, which will prevent them from being assigned a new number when saved to the platform.