Dataverse workaround wrong Autonumber Seed during Deployment
Have you ever encountered a weird issue while working with autonumber fields in your solutions? You might have noticed that when deploying them to different environments, the starting value ("seed value") sometimes resets to 1000, despite your efforts to change it. I recently faced this challenge and reached out to support for a solution. In this quick guide, I'll share a workaround that you can use until the seed value becomes solution-aware. Stay tuned for a simple trick to address this problem whenever it occurs. To be clear this is a workaround and not a long term solution. Lets hope this issue goes away soon which would make this article not relevant anymore.
First things first, let's dive into setting up a DEV environment. I've created a basic solution and table named 'Cars'. Our goal is to convert the 'Primary Name Column' into an autonumber field. However, we want this auto number to start from a specific value - let's say 10,000. This approach is essential because our client already has a substantial inventory of cars, and we aim to improve the data migration process later down the road to minimize any additional problems - that (if we are honest with ourselves) come anyways as with every data migration. Let's proceed with this adjustment to ensure a better transition for the client:
Now, this is all good. If we create a record in DEV it gets the intended number:
Now, we throw this solution into a pipeline, which, by the way, you should always do to avoid manual deployments whenever possible, and deploy it to a TEST environment to see our auto number field. What do we see? Well, we see that Power Platform changed the Autonumber back to the default seed value of 1000:
After contacting support, I was told that seed values are not solution-aware as of now (November 2023), meaning you cannot deploy them easily. This might seem weird because you might think that when you configure the column, the seed value is somehow also included in the solution, but it's not. There are methods to do that, but most of them are unsupported and/or break fundamental architectural rules. So, let's demonstrate an easy method to change this. First, go to the default solution in your TEST environment, then to the respective table and field, and change the seed value there
This will, of course, create an unmanaged layer inside your managed solution. Next, we jump back to our managed solution and remove the respective layer. This is important because the order of execution will otherwise always show this layer, and this is potentially not what you want for later deployments
There you can go on and remove the unmanaged layer:
And after completing this step you should see the "correct" seed value in your app, in our case the autonumber for the cars:
Of course, this is a workaround and is classified here as a 'Trick.' However, as long as seed values are not solution-aware, which I hope will soon happen, it is a possible way to input the correct values into your target environments if you have to use custom formats for your numbers.
Dataverse workaround wrong Autonumber Seed during Deployment
Comments
Removing unmanaged layer inside your managed solution
Hello David, thank you very much for interesting and very useful article!
I've been wondering why do you suggest remocing unmanaged layer inside your managed solution? If I understood it correctly, autonumber seed is not a part of solution, meaning I would need to repeat the same operation every single time I deploy a new solution in test environment, wouldn't I? I expect that unmanaged layer is important and should remain, so at the next deployment of test solution the seed logic remains active.
Thank you!
Hello, Unmanaged layers…
Hello,
Unmanaged layers should always be removed if you want to maintain a proper ALM using pipelines. The point is that the autonumber stays correct even after removal of the layer.
Hope this clarifies.
Greetings from the Netherlands
David
Another workaround
In my work, we use ADO release pipeline system to handle deployments of power apps.
In the advanced settings there, it is possible to enable "Export auto numbering settings".
Sure, you can do that with…
Sure, you can do that with DevOps but seed values are not part of the meta data for a reason:
- Seed values are tied to a specific dataverse record in the database, rather than to are not metadata per se, thats why they are not in the solution. Architecture wise you only want to migrate configuration (and in some cases master data) with a devops pipeline. Data which is bound to specific records usually never gets migrated as this is very bad.
- Secondly if you do that you run into the risk of overlapping 'unique' values across your environments.
That is why the correct approach according to MSFT is to actually not use seed values if you depend on the uniqueness, but rather use an external service like a Azure Function or something like that which gives unique IDs to records & keeps track of the IDs. This is how unique values should be used in Dynamcs CRM, not with the seed value.
The workaround above was just shown as a trick if you rely on those values, which might be wise to avoid in the first place.