Firefighter Log Approval Workflow

[Former Member]

Hi Everyone,

I've got an interesting one I think and would appreciate any help or advice.

In my GRC 10 SP12 system, we've configured Decentralised Firefighter and it's all working well.

I have used standard SAP Workflow but have customised the notification templates and these also work fine.

The problem I have is that the Approval email from the Firefighter Log Review is going to the wrong person.  I'll list the steps below:

GRC Administrator - so your SAP Security/GRC Resource, called GRCADMIN

Firefighter ID - the FF that is used, lets call it FF_SUPER

The End user in ECC - ENDUSER

FF Controller in GRC - CONTROLLER

OK, here's the scenario.

ENDUSER logs in to ECC and calls FF (GRCPI/GRIA_EAM)

As FF_SUPER carries out tasks and logs off.

Login Notification email is sent to the CONTROLLER

New Work Item email is sent to the CONTROLLER after the background job finishes.

The forward and return workitem emails are working fine between the CONTROLLER and the ENDUSER

Once the CONTROLLER approves (hits Submit) the Log Review report, the final approval email goes to GRCADMIN

MSMP has the notification set to GRC_REQUESTOR so I have no idea why it's being routed to a user id not even involved in the FF process.

All email addresses etc have been set up correctly as well on all the accounts in both ECC and GRC.

Any thoughts of where to check and what to look for would be great.

Thanks in advance!

Sonia

[angelam1]

Hi just wondering if a workaround/solution was ever found for this issue.

The additional information is useful if the Controller wants to ask the Firefighter a question regarding something that was executed.

[Former Member]

Sonia,

We had similar issue and I agree with Gerrit as all the firefighter logs reviews are captured inside the GRC system itself and also It's not really required to notify the user via email(nice to have) or you can create a mailbox/system mail address(outlook/notes) for all the approved end user FF log review notifications by adding the email address to the BATCH(step)user ID that's running the FF Log Job.

I think if we have the GRAC_USER Agent inside the FF Log MSMP process,it would be great.

Thanks

Ramesh

[Colleen]

Hey Sonia

Is there a chance you have not generated latest version of your MSMP configuration and you're referencing a different one?

Could MSMP have a global notification or task/step one and it's going to the GRACADMIN (close task)

It's been a while on a GRC system for me but is there a chance of any parameters having OWNER as GRCADMIN configured and for some reason they get the notification (complete stab in the dark)?

Does the GRC_REQUESTOR have a GRC SU01 account? As notification uses SOST I assume they need to have user master for it to work (again not on the system recently to check).

Regards

Colleen

[Former Member]

Hey Colleen,

Thanks for the reply.  As far as I can see, the issue has to be in my MSMP somewhere.  I've attached the data log for the workflow.  You can see the second line there - GRC_ADMIN.  Please note, that GRC_ADMIN is an actual end user account that isn't involved in the process chain at all.  Yes, all ids exist in all systems etc...

[Colleen]

Hey

what does the notifications tab show?

Check in your MSMP step for configuration of the Notification for the default path/step that you are referring to and double-check the right agent is specific.

Then check the Agent configuration for the Maintain Rules & Maintain Agents in MSMP to ensure it determines the agent you expect - this is for the step close/completion

After that, you need to go back to your Step 1 and check the Global Notification configuration for request closed event.

Based on your scene-setting, it sounds like it's the email/notification and not the routing of the item

I'm basing my comments on the blog I wrote a while back (flow diagram showing how to track the agent). Not as much focus on notification but it's on the diagram -

Regards

Colleen

[Former Member]

The other thing that I noticed, is that the FF Request is actually logged by GRC_ADMIN, not the user, so that has to be why the GRC_ADMIN is getting the approval at the end.

[Former Member]

OK.  I know what's causing it, but I have no idea how to fix it.

The workflow request is picking up the user who executes the background job.  So if GRC_ADMIN runs Firefighter Log Sync, it is picking up GRC_ADMIN as the requestor.  If I run the Log Sync, it picks me up as the requestor.  If it is run in the background by batch user, it picks up the batch user as the requestor.  It should be picking up the FF user as the requestor, not the id that runs the Log Sync report.

[Colleen]

Hey

That makes sense. Knowing the cause is half the battle

First check if this is how the program is meant to work (is there a note in marketplace identifying an error). See if raising an incident (assuming program logic for running job is incorrect).

If it's come back to this is a feature/design then you need to look at configuring your own agent rule for the notification to calculate the requester (i.e. the firefighter support person - GRC_REQUESTER).

You could be looking at building a BRF+ Agent Rule. Not sure how complex that will be and if the structure/rule type will import the information you need. Alternatively, do you have access to a developer who can write a function module?

Regards

Colleen

[Former Member]

Hi Sonia,

GRC_ADMIN being the requestor of the FF access is not the issue. I have given a try with other user; however, issue persists.

[Former Member]

Good Day Sonia

We had the same issue.

In the end, we had no other option, but to disable this notification.

We thought carefully about it and in the end, it makes sense in a way. Nowhere during the workflow, is the Firefighter actually involved. The Firefighter performs their activities and logs out. Then he/she is out of the picture. Then the background jobs actually kicks of the workflow, making the systems user, the Requester, in this case.

And in the MSMP setup, there are not many Agents to choose from. I agree with Colleen, maybe it is possible with a BRF+ rule. I also tried to create one, but without any success, nowhere during the creation could I find anything related to the Firefighter itself.

If you compare it with Access Request for example. You have 2 Agents. The Requester and the User. The Requester is the person that fills in the request and clicks the submit button. This submit button, actually kicks of the workflow. Then once approved, you can send notifications to the requester and the user (Newly created user).

Where with Log Approvals, the requester is the Background user who starts the background job. Like you mentioned, if you start the job with your user ID, you are now the requester and get the notification

It would be nice to find a solution for this issue.

Thank you

Regards

Gerrit