Managing Lifecycles
If you have ever used the To Increase platform, and lifecycles then maybe you have already had the same question I am about to ask. How do you manage lifecycles once they are in production?
The issue here, is that by default the lifecycles are set at the parameter level for a give process, say purchase requisitions for example. So you create your one lifecycle, associated it at the parameter level, and it applies to all purchase req.'s that are created.
This is great and all in the lab, but come to the real world when you have 32 lifecycles that you want to apply depending on the user, and oh yes these lifecycles need to be able to be updated and changed as needed while in production. By default you can Not do this. The solution I have found that seems to work really well is take the lifecycle association away from the parameter level and marry one lifecycle to one purchase req. By doing this, you enable yourself to copy the one you want to change, change it, and then apply it so that all New req.'s will use the new lifecycle, while current adtive req.'s still have their lifecycle to use until they have been completed.
By taking the lifecycle and marrying it to the purchasre req. at the single req. or 1-to-1 level then you can affectivly manage, update your lifecycles while in production.
Now if the single lifecycle model for all req.'s will work for you, then by all means keep the default. If not, well you will have to implement something similar to what I have described above.
Check back later for more!
Find a job at: www.DynamicsAXJobs.com
The issue here, is that by default the lifecycles are set at the parameter level for a give process, say purchase requisitions for example. So you create your one lifecycle, associated it at the parameter level, and it applies to all purchase req.'s that are created.
This is great and all in the lab, but come to the real world when you have 32 lifecycles that you want to apply depending on the user, and oh yes these lifecycles need to be able to be updated and changed as needed while in production. By default you can Not do this. The solution I have found that seems to work really well is take the lifecycle association away from the parameter level and marry one lifecycle to one purchase req. By doing this, you enable yourself to copy the one you want to change, change it, and then apply it so that all New req.'s will use the new lifecycle, while current adtive req.'s still have their lifecycle to use until they have been completed.
By taking the lifecycle and marrying it to the purchasre req. at the single req. or 1-to-1 level then you can affectivly manage, update your lifecycles while in production.
Now if the single lifecycle model for all req.'s will work for you, then by all means keep the default. If not, well you will have to implement something similar to what I have described above.
Check back later for more!
Find a job at: www.DynamicsAXJobs.com
0 Comments:
Post a Comment
<< Home