Foiled by FLS…Again

I was once again foiled by field level security. Seems to be a theme in my life lately. We had set up a basic flow that took a community user through a single screen flow to escalate a case.

All initially seemed fine. It ran well in debug mode. It then ran well once the URL button was set up. Some how during UAT we missed testing the functionality in the community as a community user.

A few weeks pass and then a flow error pops up in email. The initial flow error provided a very nondescript alert that there was a problem.

This particular flow error left a lot to be desired. It was one of the more vague ones for sure. I started digging in, replicating the error then walking through the debug mode. No problems there, then I double checked the button. Also good.

I ran it as an internal user. All perfect. Finally, running into no answer, I try it again in the community. This time I get an error that clues me in that there is an issue with the fields. I am now about 3 hours into the hunt for answers and feeling mighty ridiculous.

I should have been able to resolve this by now. The error message should have been the clue I need to remember to check the FLS. But first I went down the path… again… of dissecting the flow to confirm the fields were all still valid. I had run into that problem recently with another flow so it was top of mind. Finally it dawned on me, of course, if it works internally but not externally it had to be FLS. A quick check showed that was exactly what was wrong.

I opened up the fields to have read access, confirmed the fields were not visible on the page layouts in the community, and retested. Bingo. Flow worked. Customers could now escalate the case and we were good. Lesson learned… again… remember to check FLS when things aren’t working.

Leave a Reply

Your email address will not be published. Required fields are marked *