imthekrish Respected Contributor.
Respected Contributor.
533 views

Call a subflow as a different user(System Account)

I want to call a subflow owned by someone else from my main flow. This subflow is in different content pack than main flow. The user who has access to my flow in cantral should never be able to execute subflow alone.

no changes in subflow because i dont own it.

Is this possible ?

0 Likes
4 Replies
Outstanding Contributor.. JarodMB Outstanding Contributor..
Outstanding Contributor..

Re: Call a subflow as a different user(System Account)

Do you have access to the content source -if so import the project and add the subflow where desired

Do you have access to the content pack (but not the source) - import the content pack and use the subflow where desired

No access to either - use dynamic flow execution to call back into central to run the subflow
-------
Set permissions in central accordingly to meet your requirement
0 Likes
imthekrish Respected Contributor.
Respected Contributor.

Re: Call a subflow as a different user(System Account)

Problem is with permission setting. I have a group where i add all my users to it and give execution and view permission to the group so that if the user run the mail flow there is no access issue because use belong to a group which has access to all the subflows in my content pack/project. The subflow that i want to now call belongs to other content pack/project. i dont want to put those flows inside my project(duplicating) instead i want to call that flow which is in a different project/cp.

0 Likes
Outstanding Contributor.. JarodMB Outstanding Contributor..
Outstanding Contributor..

Re: Call a subflow as a different user(System Account)

What about giving the user group run but not view perms?
0 Likes
Micro Focus Expert
Micro Focus Expert

Re: Call a subflow as a different user(System Account)

Hi,

There are 2 different scenarios here  and they must be separated.

On one hand the "subflow" is a step in the flow. In this case the users who do not have access to this flow will run into a permission problem. This can be handled with handoff or gated transitions. On the transition prior to this step you specify that the flow must be handed off to a user belonging to a certain group. The execution will pause and some user from the group that has access to the subflow must resume it. Once their part is done you can hand off the flow again to the first group. This will indeed take longer since user interaction is required.

In this scenario there is the option of giving the first group run permissions without view permissions (as has been previously mentioned) and the users will be able to run this subflow as part (step) of a larger flow, but will not be able to see it in central. 

The second scenario is where the user will try to launch this flow as part of the flow execution via dinamycally launch flow or direct post/executions API call. In this case having a system account that belongs to the second group marked as the username/password credentials will work. In the case of post/executions the user that must have the permission to run the flow is the user which authenticates the API call.

Hope this helps,

Vlad

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.