I just don't feel respected as a customer by Salesforce forcing me to commit a bunch of sprints between now and May to arbitrarily update flows. If you query the recordtype directly in the same flow that's broken by this update, it works just fine when you use that element's queried values. It's also not like these users don't have access to the metadata anyway. Ultimately, what's silly about all of this is that there's no way to grant users access to recordtype metadata for this context, short of going way beyond reasonable least-privilege (e.g., admin-level permissions), or shifting flows to system-context. So not only was it already a problem I knew I was likely going to have to deal with before Summer '21, they introduced a bug that auto-enabled its test-run for some customers. What makes this all insult-to-injury on my end is I was already fighting Salesforce on this change after discovering its impacts in our Spring '21 regression sandbox-testing. Re: your record-triggered flow → you sure that's not running in the system context? That said, an inaccessible merge field in a formula could cause the problems you describe. To clarify, this specific release-update has to do with pulling metadata into things like decision-elements and displayText, etc. There is, however, a process automation setting that you can enable to ignore read-only fields for the running user during an update. AFAIK, Flows always respected field-level-security for DML operations of the running user. Among the Security Updates were Remove View All Users Permission from Guest User Profiles and Reduce Object Permissions for Guest Users. What you're describing does not sound related to this specific release-update, if I'm reading your comment right, though. Salesforce suggested security measures for guest users, objects, and APIs, while also pushing Security Updates in the following Winter 21 and Spring 21 releases. This release-update enforces access to that metadata too, so if your'e following flow best-practices and not hardcoding recordtype IDs, you're (like we are) going to have to spend a bunch of time updating flows before Summer '21 unless SF comes to their senses. Where it doesn't make any sense is for things like recordtype developer name. For example, it doesn't make sense that a flow would grant a user read-access to Account Billing Address through a merge-field just because the user has access to a relate case-record. I don't know exactly why they chose the term "Merge fields", but in this context they refer to the fields on a related record you get via a lookup in the field selector for a record-variable.įor example, if you query a case via Get Records, and then reference its owner's First Name.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |