What role is required to view flow execution details?

[thomaskennedy]

When I open my flow and choose More Options | Executions it shows me a list of executions for my flow. But when I click on any row I get

There was an error loading the execution details for this flow context

and a popup saying

Exception while executing request: User doesn't have permission to view the report

So I assigned myself all the roles having flow or fd in the name, like so:

flow_report_viewer
flow_designer_scripting
flow_operator

etc

However this made no difference. What do I need to view the execution for my flow?

The property com.snc.process_flow.reporting.level is set to FLOW.

[Donald B Harden]

I have this exact same issue, and I have verified com.snc.process_flow.reporting.level, my roles, etc. but I still can't view flow execution contexts.  This seemed to happen when we upgraded from Tokyo to Vancouver.  

Did you find a solution?

[thomaskennedy]

No, I never got to the bottom of this. If I remember correctly which flows these were, they wound up being so simple I stopped worrying about ever needing to see their execution details, and the issue hasn't come up anywhere else since.

[Donald B Harden]

OK,  thanks for the response.  Unfortunately the flow I am working on is rather complicated. 

[David_Leake]

We are also having this issue after upgrading to Utah release. I have found that if the flow is set to run as system user I (Admin) can't see the execution details and get the: "There was an error loading the execution details for this flow context and a popup saying Exception while executing request: User doesn't have permission to view the report" 

However, when the flow is set to run as User Who Initiates Flow and assign roles (guessing game sometimes on what roles to give). I can see the flow execution details with no error. The only issue with this is if the initiating user role doesn't have access to a table the flow will fail. So I have to keep changing between system user and user who imitates flow to see the details of execution. 

 We have updated the reporting property to On but still no change in the above behavior. 

During our upgrade to Tokyo we opened a Support ticket for this issue and this is the below response from the Ticket: 

"The issue is that after upgrading to the Utah version, users are getting the following errors when trying to view the flow/subflow context:

"There was an error loading the execution details for this flow context"
"Exception while executing request: User doesn't have permission to view the report"

This is actually an expected behavior due to a security enhancement introduced in the Tokyo release. We have PRB1509513 created for this security enhancement.

We have the KB article KB1211423 which contains a detailed explanation about why we have such security enhancement introduced in the Tokyo release.
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1211423

According to KB1211423, such security enhancement is done based on the following facts:

1. When Flow executes in the background, it runs in a different environment than the session that triggered the flow. Background sessions in which flow is running may have a different role or different user (like system) and flow can run with the role that the user doesn't have.

2. Some roles are special and have encryption context attached to them (sys_user_role.encryption_context). Those roles can be used to encrypt and decrypt in the platform and the expectation is that anyone without that role shouldn't able to see that encrypted data.

3. This was one of the security issues with the flow execution detail that any unauthorized user is able to see the encrypted data by accessing the flow execution report.

4. Flow always run with some roles either user (if it is run as a user) OR system (if flow runs as the system it takes an admin role) OR if there are any roles defined on flow and any of those roles could have encryption context attached, If someone wants to see the execution report for the context, they should have all the encryption context with which flow ran.

Therefore, this was flagged as a security issue which introduced a change in behavior in the flow designer execution detail page. It was fixed as part of PRB1509513 from Tokyo onwards.

So for example, if the flow is run as a System user. Therefore, the flow context was executed as a System user who is inheriting all roles of the Admin role.

The Admin role contains the role "sn_ind_rmt_help.admin" which contains "sn_ind_rmt_help.requester" which contains "sn_ind_rmt_help.viewer" which has Encryption Context populated.

Therefore, any user that opens the flow in the operation view must not only have the roles required to open the operation view but all roles that executed the flow context containing the encryption context.

If you want to keep using those roles with Encryption Context populated, you will have to check every single user who needs to trigger flow/sub-flow and make sure they have at least 1 of those Encryption roles assigned to them. As you currently have so many users on the platform, this solution might not be a very good option for you.

The best-recommended solution for you is to remove the encryption context from all the mentioned roles with Encryption Context populated (and make sure all the roles which the admin inherits won't have any encryption context).

Please note that this solution will not fix the existing affected flow contexts with the error because the solution will only take effect for new flow contexts created after applying the solution. Impersonating a user to verify the solution will also still not work even after applying the solution. You have to ask the affected users to log in to the platform and verify by themselves."

We didn't feel the process of review and removing the Encryption Context populated and making sure that no users have one of the encryption roles was worth the effort as a work around so we are switching back and forth when building flows. 

 Hope this information helps others as it seems this is a common issue. 

[Donald B Harden]

Thanks David for this very detailed explanation.   I really appreciate your time and effort to respond.  I've sent it to our ServiceNow admins to apply one of the proposed solutions.   Once that is done I'll update this thread.