BUG [video] - Workflow Bypass Security Filters Help

[Grant_Stead]

i wonder what i’m doing wrong?

[Steve]

User’s email is the key for the table?

When adding rows, all the table’s keys need to be visible to the app so the app can recognize the duplicate. Your security filter is blocking the app’s visibility of existing keys. If the keys aren’t visible to the app, the “new” row will replace an existing row with the same key when the row arrives at the spreadsheet. The workflow runs after the spreadsheet has been updated–after the old row has been overwritten by the new–which is why your condition doesn’t catch anything.

[Grant_Stead]

But then what is the “bypass security filters” option for?

[Grant_Stead]

Also, the PEOPLE table has a row add, the USER and USERPERM table are added via the workflow that is triggered by the PEOPLE add… So, the workflow rule may run AFTER the people record is added.

This still doesn’t explain what the “Bypass security filter” option is for. If it is’t for this, then what is it for?

[Aleksi]

“Bypass security filter” should overwrite security filter expression with the Workflow. For example… if you have a security filter as FALSE, your Workflow should still send all data.

[Grant_Stead]

So. Is this a bug? The docs make it sound like I should be able to check the conditions against the table even if the security filter is set to false…

[Jonathon]

I have a recent application where the workflow was failing to fire unless I explicitly allowed the app creator through the security filter, the same as the old behaviour.

I also have applications where the bypass security filter toggle worked as intended.

[hugheshilton]

An update on this issue. The problem was a caching issue where table data was being temporarily cached internally with the security filters applied and then that data was being used during the formula evaluation of the workflow condition. This is very short term caching of data for the current user session we’re talking about, nothing that is stored or used long term.

The reason some people have seen the bug and some haven’t is because there had to be some earlier reference being evaluated that triggered the data to be fetched before the workflow condition was evaluated. So depending on the structure of your tables and dependencies between them, the data used to evaluate the condition may not have been fetched yet in which case bypass security filters was working correctly.

A fix has been put into place for this bug which should be deployed into production a few hours from now.

[aeastham]

I still think I am still seeing this issue using an SQL DB on Azure as of Thursday Morning GMT.
The first step in my workflow creates a master record that the security filter would normally exclude from view.
The second step reads the value of the key of this new record and tries to update a field in another table with this value. This step is saying it succeeds, but the value in the second table is NULL. This implies to me that it is reading cached data that does not yet include the new row.

Best regards,

Andy Eastham

[APiCC_Conor]

@hugheshilton I believe I am experiencing this issue as well. The bypass security filter check box does not appear to function.

[Logan_Thideman]

I think I am seeing this as well. Using SQL on Azure.
Trying to trigger a notification workflow that reads a list of users from a table that is filtered. Explicitly adding creator account to the table security filters fixes the issues, but causes other problems. Leads me to believe the “Bypass security filters” function is not working.

[Phil]

Hi Conor,

I rue the day we added this feature.
It is ridiculously complicated and been an unending source of bugs.
Having said that, if you think you have found a bug, please submit a bug report.
In your bug report please include as clear a description of the problem as possible.
Make sure you include the exact steps to reproduce the problem.

[Grant_Stead]

HAHAHAHAA YES!
I feel the exact same way about some of my service offerings!