Different Workflows by Functional Area of Role

[Former Member]

Hi,

is there a chance to split/fork the workflow by functional area of role???

I created a fictuious functional area "Display" and these roles don't need any approval. For all other roles I want to use a 2 stage workflow.

Using 2 initiators doesn't work for me and I think this can not work, as I can add roles from different functional areas to one request.

Any ideas how i can solve this problem?

[Former Member · Accepted solution]

Even if you define the approval at role level, you cannot fork them seperately from the request.

What you could do as a variant of the same, is define certain authorizations as critical per se and RAR risks for the fork condition. The functions who would be expected to contain these types of requests would be forked and the display role can just tag along. Any requerst which is "vanilla" (not that display_all is "vanilla"...) would go through without the fork.

Cheers,

Julius

[koehntopp]

There are several ways to do that.

You can either create initiators which have ROLE as the main attribute (you can use the upload functionality to do that) or you can not assign approvers to display roles and select the option "auto approve roles without approvers" in role - role selection.

In that case, you may want to make sure there's an escape route for the case that your request only has display roles.

Frank.

[Former Member]

I think, using different initiators will not work, as one request wouldn't fit to exactly one initiator (think of a request with a info and a non-info-role). The info-role would trigger one initiator and the non-info role would trigger one initiator as well.

[Former Member]

My recommendation would be to drop the functional role naming convention approach.

Particularly the RAR functionality gives you the option to pull in the cross-functional conflicts. It is critical permissions and critical combinations where most of the music plays. Even "info roles" can be critical in some combinations.

Using this approach for your CUP workflow trees will have a better match to the intended functionality, and you will have less initiators to manage.

That would be my advise.

Cheers,

Julius

[Former Member]

Thanks Julius,

I solved it that way:

I have 2 initiators - one for functional are "Info" and one for NOT "Info", Choosing the functional area is obligatory - in this way I can use my 2 workflows.