Strange permissions issue on real-time workflow

(0) Share

Report

Posted on by awalters

3,079

We're working on a BPF and some accompanying workflows for an approval process on projects (a custom project entity). We have a field that is approval status, which has field security to be read-only for most staff, and write for those who can approve. The submission for approval is done through changing the stage in the BPF to "Awaiting Approval" (which of course has a number of requirements of things they need to do before they can advance). When they advance the stage, the idea was to fire a workflow that would change the approval status to "Under Review", and then email the approver that it's ready for review. This all works fine when the person submitting the project is also an approver (i.e. has write permissions to the approval status field).

However, when someone with only read permission does this, it all falls apart. The workflow to update the approval status can't run as that user, since they don't have permission. But to be triggered from the BPF, it must be an on-demand workflow, which means it has to run as the calling user. Okay - so instead of triggering it on the stage change in the BPF, I decided to trigger it as an automatic workflow, but on the change of the stageid field. In this case, it doesn't actually trigger. :-( I tried having the stage change in the BPF set a hidden field that the user did have permission to - "Project Submitted". This works fine. So then I tried having the original workflow trigger automatically (again, so it could run as the owner of the workflow rather than the user) on the change of this new field. This is where it gets interesting. I get an error, saying the user doesn't have write permission to the approval status field (which of course they don't, but the workflow that's changing that isn't being run by the user). But then the workflow runs successfully anyway, changing the approval status and sending the email like I'd expect.

As a test, I tried changing the workflow a background workflow, and there are no errors, and it works. When I look at the process sessions, I can see it's running as the workflow owner. But having it background isn't a solution, as it needs to be real-time so the user sees what's happening.

Any thoughts? Gotta admit, I'm completely stumped on this one.

*This post is locked for comments

I have the same question (0)

All responses (11)

Answers (0)

ashlega 34,477 on at

Like (0)

Report

RE: Strange permissions issue on real-time workflow

Hi Allison,

I am not sure about the second part - that sounds confusing.. but, for the first part, did you try registering that workflow on the bpf entity instead? (still so that it runs under the user who has required permissions)

Was this reply helpful? Yes No
awalters 3,079 on at

Like (0)

Report

RE: Strange permissions issue on real-time workflow

I hadn't - I didn't even know that was a thing. (Nor am I exactly sure what it would look like.) I'll play around, though, and see what I see...

Was this reply helpful? Yes No
ashlega 34,477 on at

Like (0)

Report

RE: Strange permissions issue on real-time workflow

Just look for the entity that was created for your BPF - you can register workflows on those entities, too

Was this reply helpful? Yes No
awalters 3,079 on at

Like (0)

Report

RE: Strange permissions issue on real-time workflow

Yep - just wasn't sure what the relationships looked like, or anything else - but I think I'm muddling through it. Working on re-creating it now, and will test shortly. Thanks!

Was this reply helpful? Yes No
awalters 3,079 on at

Like (0)

Report

RE: Strange permissions issue on real-time workflow

Okay, so now I have a workflow registered on the BPF entity that sets the interim field (it was already in there, so I started that way), that's running as the owner of the workflow. The second workflow (registered on the main entity) is also running as the owner of the workflow; it checks for that field to change, and changes the field most users don't have access to.

Getting the same behaviour as originally - if running as a high permission user, it works perfectly. If running as the low permission user, it gives the permissions error, but then everything happens as expected anyway.

I'll try removing the interim field, but not sure why/how that would make it better...

Was this reply helpful? Yes No
awalters 3,079 on at

Like (0)

Report

RE: Strange permissions issue on real-time workflow

Removed the interim field and set the secured field directly in the BPF workflow. Same behaviour - gives the permissions error, but still runs. :-(

Thought maybe it was running twice, with one failing and one succeeding, but there's no record of a failed run in the process session log.

Was this reply helpful? Yes No
awalters 3,079 on at

Like (0)

Report

RE: Strange permissions issue on real-time workflow

"I decided to trigger it as an automatic workflow, but on the change of the stageid field. In this case, it doesn't actually trigger."

As a quick follow up, I realised why this wasn't working - these fields aren't used (or at least not reliably?) since the changeover of the BPFs having their own entities. So one small part of the mystery solved. But the overall question still remains. For the time being we're working around it by not having it be real-time. We can sort of get away with that in this specific instance, but there are others where we were thinking of doing a similar thing where it would definitely need to be real time, so still interested if anyone has any ideas.

Was this reply helpful? Yes No
Piotr Kerner 285 on at

Like (0)

Report

RE: Strange permissions issue on real-time workflow

Hi,

This is indeed strange at first. I was able to reproduce your error and did a bit of digging to find this article:

[View:https://technet.microsoft.com/en-us/library/dn531067.aspx#BKMK_SecurityContextOfWorkflowProcesses:750:50]

It seems that the desired workflow behaviour is that background workflows triggered on demand or via "Run workflow" button will be triggered with the calling user privileges, but calling them using a trigger runs in scope of the owner.

It also seems that for real-time workflows you should be able to set the privileges to workflow owner, or person doing update.

Unfortunatelly it seems that the first part is not limited only to bakcground workers as I was getting the same error as you had when triggering the workflow on demand (and through "Run Workflow" button).

What I managed to do however is to configure the workflow to work as intended. What you should do is:

1. Set the Execute as to "The owner of the workflow"

2. In Avaliable to Run: uncheck the "As an on-demand process"

3. Set Options for Automatic Processes to "Record fields change" and select "Process Stage".

Please look at the screens below for further assistance:

Should you have any questions to the solution please contact me :)

Hope it helps

Piotr

Was this reply helpful? Yes No
awalters 3,079 on at

Like (0)

Report

RE: Strange permissions issue on real-time workflow

I had actually tried that before, and it didn't fire - likely because as I later discovered that stageid is a deprecated field as of 8.2. BPFs now have their own entities, rather than just having stage fields on the record.

Was this reply helpful? Yes No
PekkaSahlsten 827 on at

Like (0)

Report

RE: Strange permissions issue on real-time workflow

A field that still gets updated in Version 9 is Pipeline Phase (stepname). (Weirdly it gets set to the category of the BPF stage - not name.) Maybe you could trigger your workflow off of that instead?

Was this reply helpful? Yes No