locked
Auto-numbering RRS feed

  • Question

  • Hi, 

    I would like to ad a unique number to my opportunities and leads but the actual auto-numbering application within Ms Dynamics online is only for the order, quotes, etc...

    Do you know if there's any way to extend it or which (if possible free) plugin can I install to complete this task? 

    Thanks for your help

    Sylvain

    Tuesday, June 2, 2015 9:12 AM

Answers

  • Apart from the excellent tool Guido recommended for Auto Numbering, you can also achieve it using real time workflows. Refer this

    https://arunpotti.wordpress.com/2014/03/21/auto-number-generation-using-real-time-workflow-in-ms-crm-2013/

    Hope it helps!


    Regards, Abhishek Bakshi If you find this post helpful then please Vote as Helpful and Mark As Answer. Check my blog on https://mydynamicscrmblog.wordpress.com/

    • Marked as answer by sylvain_43 Wednesday, June 10, 2015 2:57 PM
    Wednesday, June 3, 2015 3:58 AM
  • Tuesday, June 2, 2015 11:00 AM
  • ADXStudio has their free Productivity pack that includes auto numbering.  It uses either a plugin or workflow methodology.  Highly recommended.

    http://community.adxstudio.com/products/adxstudio-productivity-pack/

    • Marked as answer by sylvain_43 Wednesday, June 10, 2015 2:57 PM
    Tuesday, June 2, 2015 1:48 PM
  • The trick is to update a dummy field on the Counter record in the step prior to incrementing the counter value on the counter record. 

    This will effectively open a SQL transaction that locks the counter record from being updated by any other process during the transaction which will end at the end of your real-time workflow. 

    So create a new field on your counter entity, call it something like "Counter Lock".  Then in the workflow before the increment value step, add a new step to set the Counter Lock field value to the current date/time, then in the next step go a head and increment the counter value by 1, finally copy the current counter value to your contact.

    Hope this helps.

    • Marked as answer by sylvain_43 Wednesday, June 10, 2015 2:57 PM
    Wednesday, June 3, 2015 9:40 PM
  • Since this will be handled through real time workflows, I dont think there would be a problem. As Jukka quotes "It’s all due to the fact that the real-time workflow runs inside the database transaction, meaning that all of the steps in it are part of a single transaction (including the record creation in our example). This is what allows the real-time workflows to abort the operation and it also ensures that another competing workflow doesn’t get a chance to mess with the process of retrieving the counter value. The real-time workflows are executed in either pre-operation or post-operation stages of CRM’s Event Execution Pipeline and are therefore guaranteed to be part of the database transaction."

    http://survivingcrm.com/2013/12/auto-numbering-workflows-real-time-vs-asynchronous/


    Regards, Abhishek Bakshi If you find this post helpful then please Vote as Helpful and Mark As Answer. Check my blog on https://mydynamicscrmblog.wordpress.com/

    • Marked as answer by sylvain_43 Wednesday, June 10, 2015 2:57 PM
    Thursday, June 4, 2015 4:26 AM
  • Yes it runs in transaction, however the counter record is not locked within the transaction until a write operation is performed on it.  The Increment operation is a shortcut for both Read and Update operations, so it is possible that two instances of the workflow both read the same value then attempt to update that record with the same updated value: i.e. Workflow A and B both read the same value of 10, then workflow A wins the race to update the record with value 11 and completes it's run releasing the record to be updated by workflow B, which has already read the value of 10 so updates the record with a value of 11. 

    This is a common condition in any multi-threaded system and must be handled.  The way to safely do this is to lock the counter record into the transaction before reading the value - since Increment IS the read and update you must first update another value on the record in a prior step - I choose to update a date field with the current date/time but any update would work as long as the update hits the database and locks the record in transaction.

    • Marked as answer by sylvain_43 Wednesday, June 10, 2015 2:57 PM
    Friday, June 5, 2015 9:35 PM

All replies

  • Tuesday, June 2, 2015 11:00 AM
  • ADXStudio has their free Productivity pack that includes auto numbering.  It uses either a plugin or workflow methodology.  Highly recommended.

    http://community.adxstudio.com/products/adxstudio-productivity-pack/

    • Marked as answer by sylvain_43 Wednesday, June 10, 2015 2:57 PM
    Tuesday, June 2, 2015 1:48 PM
  • Apart from the excellent tool Guido recommended for Auto Numbering, you can also achieve it using real time workflows. Refer this

    https://arunpotti.wordpress.com/2014/03/21/auto-number-generation-using-real-time-workflow-in-ms-crm-2013/

    Hope it helps!


    Regards, Abhishek Bakshi If you find this post helpful then please Vote as Helpful and Mark As Answer. Check my blog on https://mydynamicscrmblog.wordpress.com/

    • Marked as answer by sylvain_43 Wednesday, June 10, 2015 2:57 PM
    Wednesday, June 3, 2015 3:58 AM
  • Thanks for all your reply,

    I am currently trying the real time workflows solution, but how can I be sur that when two contacts are created at the same time there will be two different ID?

    Wednesday, June 3, 2015 2:08 PM
  • The trick is to update a dummy field on the Counter record in the step prior to incrementing the counter value on the counter record. 

    This will effectively open a SQL transaction that locks the counter record from being updated by any other process during the transaction which will end at the end of your real-time workflow. 

    So create a new field on your counter entity, call it something like "Counter Lock".  Then in the workflow before the increment value step, add a new step to set the Counter Lock field value to the current date/time, then in the next step go a head and increment the counter value by 1, finally copy the current counter value to your contact.

    Hope this helps.

    • Marked as answer by sylvain_43 Wednesday, June 10, 2015 2:57 PM
    Wednesday, June 3, 2015 9:40 PM
  • Since this will be handled through real time workflows, I dont think there would be a problem. As Jukka quotes "It’s all due to the fact that the real-time workflow runs inside the database transaction, meaning that all of the steps in it are part of a single transaction (including the record creation in our example). This is what allows the real-time workflows to abort the operation and it also ensures that another competing workflow doesn’t get a chance to mess with the process of retrieving the counter value. The real-time workflows are executed in either pre-operation or post-operation stages of CRM’s Event Execution Pipeline and are therefore guaranteed to be part of the database transaction."

    http://survivingcrm.com/2013/12/auto-numbering-workflows-real-time-vs-asynchronous/


    Regards, Abhishek Bakshi If you find this post helpful then please Vote as Helpful and Mark As Answer. Check my blog on https://mydynamicscrmblog.wordpress.com/

    • Marked as answer by sylvain_43 Wednesday, June 10, 2015 2:57 PM
    Thursday, June 4, 2015 4:26 AM
  • Yes it runs in transaction, however the counter record is not locked within the transaction until a write operation is performed on it.  The Increment operation is a shortcut for both Read and Update operations, so it is possible that two instances of the workflow both read the same value then attempt to update that record with the same updated value: i.e. Workflow A and B both read the same value of 10, then workflow A wins the race to update the record with value 11 and completes it's run releasing the record to be updated by workflow B, which has already read the value of 10 so updates the record with a value of 11. 

    This is a common condition in any multi-threaded system and must be handled.  The way to safely do this is to lock the counter record into the transaction before reading the value - since Increment IS the read and update you must first update another value on the record in a prior step - I choose to update a date field with the current date/time but any update would work as long as the update hits the database and locks the record in transaction.

    • Marked as answer by sylvain_43 Wednesday, June 10, 2015 2:57 PM
    Friday, June 5, 2015 9:35 PM
  • Ok thanks to everybody, I have downloaded the productivity pack and created a real-time workflow to deal with the auto-number. 

    Wednesday, June 10, 2015 2:57 PM