25R1 Permissions at Workflow level not working for me

Hi,

I investigated the issue you mentioned. It appears you're attempting to execute a Workflow using the Workflow command. This requires either External Access or Full Access, as it does not work with Internal Access.

If you're encountering the issue even after granting Full Access, it could be due to one of the following reasons:

1. There may be a cascade Workflow involved that hasn't been granted the necessary access.
2. The newly created user may not have the necessary permissions to execute the REST endpoint

Thank you for your answer, but I do not think any of the reasons apply.

Ad 1.: I am certain no other workflows cascade from this.

Ad 2.: I double checked the basic users indeed has the basic permission set with the workflow.

This is my workflow (it is not actually useful, just a test):

(SalesContractHandling projection is normally not accessible to basic user)

To dispel any doubts around triggering the workflow from a Workflow command, I switched to this trigger (again, not actually useful, just something I can easily trigger for test purposes):

And here is the grant on our basic user permission set (with full access to make sure):

User who normally has access to the projection can trigger and execute the workflow without issue. User with our basic permission set still gets the error. I can’t be entirely sure it is the exact error I wrote about in my original post (FndProjectionGrant.SRV_NOT_ACCESS) because I get that from rerunning the workflow for inspection from the observed run, but it certainly is some 403-unauthorized error.

Any other ideas would be greatly appreciated :)

Hi,

By design, Workflow Level Permission Sets are only supported in Production Mode. If the workflow is running in Troubleshoot Mode, it should return an error that you mentioned (FndProjectionGrant.SRV_NOT_ACCESS) .This is the expected behavior for Workflow Level Permission Sets. We will mention this in Techdoc and update it.

Yes, I get that, but even when the basic viewer triggers the workflow the “correct way” - via the projection action, the workflow triggers but runs into an error.

*basic USER not viewer, sorry

Hi,

If you do not have permission to trigger the Projection Action or execute the workflow, the following error message should be returned in Production Mode.

Therefore, it would be great if you could share the error message along with relevant screenshots.

Additionally, I’d like to know how permissions are granted to users. Are they assigned individually or through a group?
We’ve already identified and resolved an issue related to Group-based permission grants, and the fix will be available in the next release.
However, if permissions are granted individually, everything should work as expected.
In our environments, we haven’t observed any issues when triggering workflow via read projection action while using individual grants.

I see, permission sets are indeed granted via user groups. I will try again later with a direct grant of the workflow to the user and let you know. Thank you!

The error message is exactly what you shared.

Just to update: I tried granting the permission set (which contains the workflow) directly to the user (not via a user group) and it works.

Sadly, until the fix for group-based permissions is available, we won’t be able to use permissions at workflow level, as we assign permission sets via user groups. Looking forward to the fix :)

I have the same issue, with a cascaded workflow.
Both workflows are granted with External Access, The first workflow fails with:
FndProjectionGrant.SRV_NOT_ACCESS: You cannot access the service JtTaskEntity

Hi ​@RHam23 ,

Is your cascade workflow triggered by an event action for the JtTaskEntity LU?

Yes: The cascaded WF is connected to the JtTask entity using Custom events

Hi ​@RHam23 ,

From the Permissions at Workflow level feature, the following is covered: if you use a projection in an IFS API task within a workflow that is not granted to the user, but you grant workflow permission to that permission set, then the user can execute the workflow.

However, in this case, the issue occurs before executing the workflow. There is a step to resolve the data types, and during that step it tries to get an authorized connection using the JtTaskEntity entity service API in your case. Since the projection is not granted to the user, the issue may occur with the error:
FndProjectionGrant.SRV_NOT_ACCESS: You cannot access the service JtTaskEntity.

As a workaround for now, if the JtTaskEntity API is not active, you can activate it from the API Explorer and grant the permission to the user.

A fix is planned for this issue in the following releases:

24.1.21 - 24R1 SU21, 24.2.15 - 24R2 SU15, 25.1.9 - 25R1 SU9, 25.2.3 - 25R2 SU3, 26.2E.0 - 26R2 EA

This worked. Looking forward for the fix

​@pdollk Is there any known limitation that does not allow workflow grants to be inherited from nested functional role permission sets? Our permission structure looks something like this: 1 end user role is granted to a user group. That end user role has no projection permissions, but it has a group of functional role permission sets granted to it.

The functional role permission sets are where the projection permissions are assigned. This is great because different end user permission sets can use the same functional role permission set and if something is changed, all end users inherit the change at the same time. However, I also granted workflows at the functional role level, and I kept getting a permission error when the workflow got run by a user with an end user set that inherited the functional role set. When I moved the workflow out of the inherited functional role and into the end user permission set, the permission error was resolved. Shouldn’t the workflow grants from the functional role be inherited by end user roles (or other functional roles, for that matter) that the functional role is granted to, just like projection grants?

We are on 25.2.3

Hi ​@dritter 

I tried to recreate your issue. I hope I recreated it correctly.

Created a functional role permission set PD_TEST_FUNCT and granted a projection and a workflow (not related to each other)

Created an end user role permission set PD_TEST_USER and did not grant a projection or workflow, but granted PD_TEST_FUNCT
Checked that the projection and workflow are listed under PD_TEST_USER, which are granted from PD_TEST_FUNCT
Observations: only the projection is listed, no workflows

Created another end user role permission set PD_TEST_USER_1 and granted a projection and a workflow

Granted PD_TEST_USER_1 to PD_TEST_USER, and the projection and workflow are listed under PD_TEST_USER, which are granted from PD_TEST_USER_1
Observations: only the projection is listed, no workflows

(Here are the common screenshots for both scenarios for the PD_TEST_USER permission set)

Permission set hierarchy showed like this

It seems that workflow grants are not allowed to be inherited from nested functional or end user role permission sets. It might be a limitation, and you should move the workflow-level permission grant out of the inherited functional user role and into the parent end user permission set (as in this example, PD_TEST_USER)

Hi ​@dritter 

I tried to recreate your issue. I hope I recreated it correctly.

Created a functional role permission set PD_TEST_FUNCT and granted a projection and a workflow (not related to each other)

Created an end user role permission set PD_TEST_USER and did not grant a projection or workflow, but granted PD_TEST_FUNCT
Checked that the projection and workflow are listed under PD_TEST_USER, which are granted from PD_TEST_FUNCT
Observations: only the projection is listed, no workflows

Created another end user role permission set PD_TEST_USER_1 and granted a projection and a workflow

Granted PD_TEST_USER_1 to PD_TEST_USER, and the projection and workflow are listed under PD_TEST_USER, which are granted from PD_TEST_USER_1
Observations: only the projection is listed, no workflows

(Here are the common screenshots for both scenarios for the PD_TEST_USER permission set)

Permission set hierarchy showed like this

It seems that workflow grants are not allowed to be inherited from nested functional or end user role permission sets. It might be a limitation, and you should move the workflow-level permission grant out of the inherited functional user role and into the parent end user permission set (as in this example, PD_TEST_USER)

Yes, that is exactly my problem. For now we will assign the workflow grants directly to the end user role, but it would be nice if they could be inherited in the future, like other permission grants.

Thank you,

Dylan

​@pdollk Are there any known limitations to how the workflows are triggered for this permission setup to work properly?

For example, let’s we have a workflow that reads from StatesHandling when a new delivery address is created on a customer. This projection is not normally accessible to this user. We’ve added that workflow to the user’s end user permission set and when they create a new delivery address on the Customer page, everything works fine without access to the projection. However, there is an option on sales quotations and business opportunities to create new customers/prospects through the Quick Register Account assistant. This assistant creates a new customer account along with a delivery and document address and some sales information. Since a new delivery address is created, the workflow is triggered, but it throws a permission error. I am positive that StatesHandling is the only projection that the user doesn’t have access to inside the workflow, and once I grant direct access to that projection, the permission error is eliminated and the workflow runs properly.

So, it appears that the workflow permissions are treated differently based on how the workflow is triggered, which seems counterintuitive to the idea of adding workflow permissions like this in the first place. We want the users to be able to trigger the workflow without normal front-end access to these projections, regardless of what process hits the trigger that we setup for the workflow. Is there any documentation of this limitation and do we know if IFS will work to fix it?

Thank you as always,

Dylan

Hi Dylan,

This is the only Tech Doc I could find regarding workflow permissions. Workflows - Technical Documentation For IFS Cloud

• What does the error message say?
• What is the IFS version you are using?
• Does the permission issue occur when you trigger the workflow?
• Or does it occur in the middle of the workflow execution?
• How is the workflow triggered (via a projection action or an event action)?
• Are you getting the same kind of error described in the above?

  Hi ​@RHam23 ,

  From the Permissions at Workflow level feature, the following is covered: if you use a projection in an IFS API task within a workflow that is not granted to the user, but you grant workflow permission to that permission set, then the user can execute the workflow.

  However, in this case, the issue occurs before executing the workflow. There is a step to resolve the data types, and during that step it tries to get an authorized connection using the JtTaskEntity entity service API in your case. Since the projection is not granted to the user, the issue may occur with the error:
  FndProjectionGrant.SRV_NOT_ACCESS: You cannot access the service JtTaskEntity.

  As a workaround for now, if the JtTaskEntity API is not active, you can activate it from the API Explorer and grant the permission to the user.

  A fix is planned for this issue in the following releases:

  24.1.21 - 24R1 SU21, 24.2.15 - 24R2 SU15, 25.1.9 - 25R1 SU9, 25.2.3 - 25R2 SU3, 26.2E.0 - 26R2 EA

   

As far as I know, workflow permissions are not treated differently based on how the workflow is triggered.

One of the goals of introducing workflow-level permissions was to allow users to trigger workflows without requiring direct front-end access to the projections used by the workflow.

Workflow-level permissions only bypass permissions on the projections used within the workflow (IFS API Tasks) when the workflow is granted to a permission set.

The level of access depends on the grant type you provide (External, Internal, or Full).

Also, make sure that the specific projection is listed under Available Projections.
​@Chanaka Perera I hope I'm correct ☝

If you can provide the OData logs captured when the error occurs, we may be able to investigate the issue further.

Yes. Essentially, WF permissions allow users to access only the WF API level without granting full access to the underlying functionality.