Changing Lifecycle state phase owners based on category schema values
We are using RAM 7.5.0.2 We have a requirement where we would like the phase owners in a lifecycle state to change based on the one of the category schema . For example: if we have a category schema called "Asset Type", and say the asset moves from state S1 to S2:
To achieve this, we used the default policy - Modify Asset Owner policy in the lifecycle configuration as follows -
2. In the lifecycle state transition S1 -> S2 , we used logical conditions (AND, OR) and configured it as follows -
Based on the above configuration, when we carried out the tests, we got the following results : When Asset type -> Requirements , phase owner changes to the Z1, Z2 and Z3 When Asset type -> Specifications, phase owner changes to Z1, Z2, Z3 When Asset type -> any other value, phase owner changes to Z1, Z2 and Z3. Since the "Other Reviewer Group" is the last policy configured in state S1, it seems to take precedence over the logical conditions configured during state transition. Are we doing something wrong? What is the purpose of logical conditions in a state if it does not work? Please advise. Thanks! Regards, Sripriya |
3 answers
All of those policies always run on the event(s) selected for that policy (e.g. as on every asset update or on upon entry into the state, or upon action). Since all four are running, they run in the sequence you gave it. Since Other Reviewer Group is the last policy in the list it runs after the other three have run. So each one runs in order, changing the owners as you go, to whatever the current policies list of owners is configured.
The transition list is not "executed" until after all of the policies have run for the given event. It then decides on how to transition depending upon the results of the conditions. Typically the policies are used for some sort of validation. Then the transition would check if that specific policy had failed the asset then it would take a fail transition or prevent an approved transition. You would need to write your own policy to have it take into consideration the categorization for determining the owners. |
I think there is an additional solution to solve this challenge. Create workflow A with conditions for all assets with Asset Type -> Specifications, the phase owners should change to X1, X2, & X3. When the asset moves from the "Draft" to the "Scoped" state (i.e. during the transition), change the owners to X1, X2, & X3. Next, create a copy of workflow A, called workflow B, and change the conditions to enter the workflow for all assets with Asset type -> Specifications, phase owner changes to Y1, Y2, & Y3. When the asset moves from the "Draft" to the "Scoped" state (i.e. during the transition), change the owners to Y1, Y2, & Y3. Next, create a copy of workflow A, called workflow C, and change the conditions to enter the workflow for all assets with Asset type -> Specifications, phase owner changes to Z1, Z2, & Z3. When the asset is moved from the "Draft" to the "Scoped" state (i.e. during the transition), change the owners to Z1, Z2, & Z3. Assets will enter the workflow that meet the conditions and make the owner changes. Comments
Sripriya Karimpuzhasriram
commented Mar 26 '13, 8:30 a.m.
Thanks much for this info. We already tried this method. It works like a charm but the only disadvantage is the problem with maintaining multiple lifecycles. Hence we wanted to research the approach of a single lifecycle and conditions during transition. :) |
Then a custom policy or a custom workflow should work.
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
Why is the need to run these policies on a transition; given that only asset update or entrance to the state will require ownership change?
Hi Gili,
When an asset is submitted, it is in the "Draft" state. When the asset is moved from the "Draft" to the "Scoped" state (i.e. during the transition), we would like the phase owners to be changed depending on the categorization of the asset.
Hence, we hoped that if we apply logical conditions using asset categorization and modify asset owner policy, it would help us achieve the objective we have in mind.
When you drive an action (move to the next state for example) you do not really update the asset's content/meta ... so the policy check is not needed, if it was applied on the update phase.