I get the point. I agree that I normally wouldn’t want to check for a User Role inside an asynchronous process; however, I am asking in the context of potentially reusing an existing codebase (where the actions already perform these checks) and whether that forces me to define new actions just for the timer/BPT or refactor the existing ones for a cleaner organization.

An example that comes to mind is a Delete_MyEntity action with the CheckRole() that originally was only called from a Screen Action (that maybe does some additional cleanup, auxiliary entity records being deleted, etc.). Now in the future I might want to directly reuse the Delete_MyEntity action for some asynchronous cleanup/purging process inside a scheduled timer/BPT Process. Not sure if this helps understand the intention of my question beyond the expected use of asynchronous processes. The question just came to me mostly out of curiosity, so for practical purposes you could just interpret it as a “what happens if..?” type of question.

So just to make sure I understand everything, for the last thing, does that mean the CheckRole() actions will always return False for those cases (i.e. GetUserId() = NullIdentifier())? 

EDIT: Similarly, is there a way to check  whether the action is running from a BPT Process / Timer or synchronously from a user session?

Hi Francisco,

Yes, CheckRole will always return False and GetUserId() will return NullIdentifier() in BPT and Timers (and on exposed Rest API's calls by the way).

What you can do is create a Wrapper that does the CheckRole and is called on screens, and you call the action on the BPT. In this way, you can reuse the action.

For instance, let's say the action you want to reuse is CreatePatient. You can create a Wrapper_CreatePatient that includes the role check before calling the CreatePatient action:

The Wrapper_CreatePatient would be call on screens where you have the user context and it makes sense the role checking and on asynchronous processes you call the CreatePatient action.