How to restrict duplicate Promotion Request for an Object

[aarasan-3]

Hi,

Has anyone come across the below scenario. I would like to understand more on this.

We use the OOTB Promotion request Workflow process for an object and after raising a Promotion Request, in the Approvel Promotion request task when the approver sends it back for rework the primary object goes back to Inwork state. At this point in time, we need to restrict the users to create another Promotion Request for the Primary object, as the ACL would let the user to create a Promotion Request. Can this be achieved through any of the OOTB options or should we go only through the validator route and write a piece of code?

Thanks in Advance!

Amarkarthi.

[ShirishMorkhade]

Hi @aarasan-3,

As far as my understanding is concerned, I dont think there is any OOTB setting/preference/command to let you do this (disable another promotion request if one is already running).

What I guess is, you can write your custom validator and hook for OOTB Promotion Request action.

In this class you can put your logic to check whether there is existing Promotion Request running on the object.

If yes, disable New Promotion Request action else keep this enable.

I hope this answers your concern.

Best Regards,

Shirish

[MikeLockwood]

If the lifecycle is correctly set up, on creation of a Promotion Request, the data on it will go to the "lock" state (e.g. Under Review).  There should be no Promote transition at that state, which prevents another PR from being created.

Note: OTB, there is a bizarre behavior in the lifecycle admin UI that fills in the Promote transition from every state to every state on the first SAVE of any new Lifecycle template.  Absolutely amazing that this remains there after all these releases.  Have to explicitly remove Promote from the lock state to any other state.

[JHall]

@MikeLockwood 
I think one thing that would certainly help would be an Icon indicating that this object was on a Promotion Request just like they show up on ECRs and ECNs. 

I'm really surprised they don't appear anywhere that I've found.

Which now makes me wonder if we could make them appear....

James

[pmoothedath-2]

Upon Rework, can you have it go to another state (like Rework) instead of In-Work. I think this will help you achieve the requirement. 

[d_graham]

I know this is an old thread but it's still relevant.

There are a few ways to stop duplicate active Promotion Request.

• Intercept it at the start of the workflow process.
• A listener can be written to stop the user in their tracks when creating or editing a Promotion Request.
• A form delegate can be written to stop the users in their tracks when creating or editing a Promotion Request.

The user would see something like below if using either a listener or a custom form delegate.

In this example, the seed is the only object that is not on an active Promotion Request.

One of the other objects is on one active Promotion Request, the other is on several (for demo purposes) Promotion Request.

Upon select Finish, the user is return the follow and they cannot continue until they remove the two problem promotable objects.

Something to think about.

David

[d_graham]

Wanted to add this to my post (but Edit option had timed out), if you go the form delegate route, you should use two delegates.

1. One for Create new
2. One for Edit

If you only have the create new delegate, the user will be able to add promotable objects that are already on an active Promotion Request when editing a Promotion Request.

David

[d_graham]

I thought I'd add to this post something I was asked about regarding creating new Promotion Request,

Not only do duplicates need to be automatically stopped but also a specific workflow process MUST be selected if the promotion request contained a specific object type or sub-type.

Below is what I came up with.

Create new Promotion Request that does not have the special sub type.

All workflows are available.

Select Back button and add object of special sub type.

Workflow is automatically selected and CANNOT be edited by the user.

The reason why this workflow is automatically selected is also displayed to the user.

Seems to work well.

David