Change Approvers

[Awalker]

Good Morning, 

Can you let me know if we have a way to alter a BPM that requires approval part way through to stop the requester approving said request if that makes sense?

For Example;

Jim raises a Change request, and it gets to the point of needing to be approved, now at present he is given 50% in approval in the BPM, but ideally i would like for him not to have the option to approve his own request, but still be an approver for a request that is not raised by himself.

Please let me know if that does not make sense.

[Victor]

@Awalker on top of my head, there might be a way if what I am thinking can be applied... would you be able to export your Bp and send it to me? I want to have a look and see if possible...

[Awalker]

@Victor

 

Absolutely, however how do i go about doing this?

 

Do you require the definition file?

[Victor]

@Awalker in BP management interface there is an option to export the BP definition file and this should create TXT file. You can send it to us at hornbill.support@hornbill com, mark it for my attention and I'll have a look..

[Awalker]

HI @Victor

 

This has been sent

[Victor]

@Awalker got it, thanks! .. I'll post an update as soon as I get a chance to look at it  

[Victor]

@Awalker so, following the email I sent you earlier below are the changes I made to the BP:

- normal and emergency changes now follow the same path - the reason is that from what I see the only difference was the authorisation task name (normal or emergency) which now populates from previous task outcome;

- there is a decision node for request owner - for each designated authorisers there is a decision node in which, if the criteria is met (meaning request owners is one of these) it creates a specific set of authorisation tasks, excluding the task for request owner (I hope this is what you wanted);

- the full decision tree is now grouped for a bit more clarity on the process diagram - also removed some redundant nodes.

Let us know how it works

[Awalker]

Hi @Victor,

 

That is excellent, i have now uploaded this and will being to test and review the process, also really like the decision grouping.

 

Thank you very much for your help and support.

[Victor]

No worries

[Awalker]

@Victor I ahve tried this today and unfortunately it is not working as desired, the customer still has the option to approve the change request, can you please advise?

[Victor]

@Awalker sorry, I was not in the office last week. Can you give me a reference example where this happened? I need to see how the BP works in that context, maybe I missed a scenario...

[Awalker]

Hi @Victor,

 

A change request was raised by David Finn, he has has 60% approval assigned to him via the authorisation node, when the CR got to the point of approval, he still had an activity assigned to him for approval and he was able to progress the CR.

[Victor]

@Awalker what is the CR reference?

[Awalker]

@Victor CH00000122

[Awalker]

Hi @Victor,

 

Did you manage to take a look at the above?

[Victor]

@Awalker apologies, I was away for a few weeks. Will have a look now and see what's going on.

 

EDIT: I had a look and I suspect is due to how BP handles users either by user name or handle. I have added some additional checks in the nodes, have a look if new raised changes still create the task for the change owner. (the amended process is CCG_Change Request_Non Elevated Access, if you have other processes using this they would need to be amended as well..let me know on this)

[Awalker]

HI @Victor,

Apologies, its looks as though it has worked, but it is working the wrong way round. As part of my Process the first step once a change request has been raised is someone assigned to the change team needs to assign it to an analyst, the process then stops the assigned analyst from approving the change, whereas what i am trying to do is to stop the customer who raised the request from having that ability, as currently they still can.

 

if that makes sense?

[Victor]

@Awalker ah, I see, wel... theoretically should be possible, I'll have a look at few examples in your instance and see if I can come up with some BP rules to cater for your scenario...

[Awalker]

@Victor excellent really appreciate your help on this, would be good to get this nailed

 

Hope all is well.

[Victor]

@Awalker so, to make sure I understand this correctly, for example:

Scenario A: Han Solo is a member of the change management team, one of the persons able to do the authorisation to proceed. Han raises a change request where he is the customer on the request. In this scenario, although he is a member of the change team, Han should not be able to authorise this change. (although he always seems to get around things funny enough);

Scenario B: Darth Vader is NOT a member of the change management team. Vader raises a change request where he is the customer on the request. In this scenario any member of the change management team (e.g. Han, Leia, etc.) should be able to authorise teh change as Vader has nothing to do with this team (although he might be able to do anything he wants, he knows the force quite well).

Jokes aside, I hope this is how the process works (or should work) for you...

[Awalker]

@Victor, the force runs strong through your scenarios, these are correct.

[Victor]

@Awalker I made a change to "CCG_Change Request_Non Elevated Access" process which I think caters for these scenarios... Give it a try, I can only hope the force is strong with me as well...

(*jedi waving hand) ... Your process works now...

[Awalker]

@Victor i will run some tests now to see if this process has returned from the dark side

[Victor]

Ermmm... might have missed one branch  ...

EDIT: ...or not... but.. on 151, how come you have all these the "Authorisation To Proceed [Normal]" tasks?... I don't see where all these tasks were created, the BP only supposed to create these 5 "Authorisation To Proceed [Normal Change]" tasks....

[Awalker]

@Victor Thank you for the help in updating the BP, the requested change now works as intended, however: -

 

The process now fails once a change is updated to Implemented, Can you please help me identify why this is as i am unable to confirm this nor can i find further description of the error in the log files as the filter does not seem to work.

 

Error Attached.