Assessment and Resolution Recommendations
Important Dates: January 10, when these are due in your org. February 6, Spring ‘21 starts rolling out. February 7, the day Red Argyle hired me, 9 years ago.
What are the common themes? Security and efficiency.
Check for Null Record Variables or Null Values of Lookup Relationship Fields in Process and Flow Formulas
What’s Changing? In processes and flows, a formula can reference a record’s field via a lookup relationship field or record variable. If the lookup relationship field or record variable is null, the formula sometimes returns null. Otherwise, it returns an unhandled exception. With this update, the formula always returns a null value when the lookup relationship field or record variable is null. This update doesn’t affect merge fields.
How do I know if my org is affected? Each Process Builder and Flow will need to be reviewed for formulas. Each formula will need to be reviewed for record variables and lookup relationship fields. If a formula contains a record variable or lookup relationship field, confirm a logic check has been/will be performed on the variable or field to determine if it is null before trying to reference the values within.
In Process Builder, you’ll need to look in these places for formulas:
- Criteria Elements where the option “criteria are met” is selected and Type “Formula” is selected
- Criteria Elements where the option “formula evaluates to true” is selected
- In Action Elements where the type “formula” is selected at any level
In Flow, you’ll need to look in these places for formulas:
- Formula elements, straightforward, eh?
Flow Example:
In the screenshot above, if the curContact variable or the Account lookup on the curContact was null, an exception would occur.
Process Builder Example:
In the screenshot above, if the Account lookup on the Case was null, this would result in a null reference error.
How do I fix errors from the null values?
After a Get Record(s) element in a flow, a decision element may be needed to determine if the variable(s) are null as a result of the query. If null, a different path may need to be taken or a new instance of a record can be created to prevent null reference errors in formulas.
For both Processes and flows, in formulas, a null check may need to be performed before the actual formula output is determined, i.e. a formula is created to determine if a custom object Portfolio’s related Account (lookup) is Active (custom field). The formula may need to contain a logic check if the Portfolio record is not null and the Portfolio’s related Account is not null before outputting True or false based on the checkbox value of the Active__c field.
If (NOT(ISNULL({!varPortfolio})) && NOT(ISNULL({!varPortfolio.Account__c})), {!varPortfolio.Account__r.Active__c}, false)
What happens if I do nothing? Kaboom, jk. You’ll be fine. This will make failures happen more consistently. If you built workarounds for those failures in the past, they’ll still work and maybe even better.
Enable Partial Save for Invocable Actions
What’s Changing? Without this update, if one invocable action fails, other invocable actions in the same transaction are rolled back. With this update, Salesforce tries three times to execute the invocable actions that run successfully and rolls back only the invocable actions that fail to execute. This functionality is called “partial save.”
How do I know if my org is affected? This takes a bit of knowledge about your org, transactions, and maybe even some Apex.
Consideration: If it’s a single Invocable Action instead of a chain, it is not affected as there could be no partial save with one. Only transactions with multiple Invocable Actions contained could be affected and improved by this update.
Consideration: Everything within a single transaction could be affected, meaning you may need to look across multiple metadata elements to determine if there is a chain.
For custom Invocable Actions using Apex, you’ll need to review all Apex methods in your org (that are not a part of a managed package) that have the @InvocableMethod annotation. This review requires knowledge of the org, or a lot of time to dig through the code to understand all of the actions within the transaction.
One way to find these methods is to search your org metadata files using the Developer Console.
- In the Developer Console, in the Edit Menu, click “Search in Files”.
- Search @InvocableMethod using the UI that pops up.
- Select a result and click “Open Selection” to open the Apex class that contains the Invocable Method.
- Review.
Invocable Actions can be used in Flows and Einstein Next Best Action, so you’ll need to review your configurations on those as well.
For Flows, you’ll want to review each to see which have Action elements.
For Einstein Next Best Action, there are three main integration points that require Apex Invocable Actions: Generate, Enhance, and External Connections; review them all.
How do I fix this? This doesn’t require any action. This is an upgrade and should make your processes run more efficiently. Action may be required however if you built any fail-safe or retry scenarios into your transactions, now would be the time to remove them.
What happens if I do nothing? Nothing will break, but any workarounds you have in place may be unnecessary now. Time to clean the house.
Enforce Data Access in Flow Merge Fields
What’s Changing? With this update enabled, a flow merge field that accesses a related record respects the running user’s object permissions, field-level access, and record-level access such as sharing rules.
Without this update, the flow interview will ignore record-level security and access a field in a merge field, leading to data vulnerabilities.
How do I know if my org is affected? Each Flow will need to be reviewed for formulas. Each formula will need to be reviewed for merge fields on records that have object-level, field-level, or record-level security.
The best approach is to test all flow paths using formulas to access fields on records with this update enabled in a sandbox. This will let you find who/what will be affected. Then you can look into the security configurations for your org and determine next steps.
In Flow, you’ll need to look in these places for formulas:
- Formula elements, for merge fields on records.
To find out what object-level security is setup for the record object, check out these:
- Organization-Wide Defaults in Sharing settings
- Profiles and Permission Sets Object Permissions
To find out what field-level security is set up for the field to be accessed, check out these:
- Field-Level Security on the Field definition in Object Manager
- Profiles and Permission Sets Field Permissions
- Page Layouts for the object where the Field is displayed on the layout
- Field Accessibility in Setup > Security > Field Accessibility or on the Field definition in Object Manager, this includes Field-level security, profile and page layout accessibility.
To find out what record-level security is set up for the record, check out these:
- Sharing on the record, for manual and automatic sharing
- Sharing Rules, for owner-based and criteria-based automatic sharing
How do I fix my access issues? If your tests and/or research find fields that are not accessible in flows with this update enabled, you’ll need to update your object-level, field-level, or record-level security to allow the running user to access the data.
What happens if I do nothing? If you haven’t recently reviewed and updated your security in your org, your flows are gonna break. And even then, if you weren’t enforcing security in your flows before, it will now become apparent. This is one of the most important updates to review.
Make Flows Respect Access Modifiers for Legacy Apex Actions
What’s Changing? With this update enabled, flows fail if they contain a public legacy Apex action. Developers can trust that their legacy Apex actions are properly protected and available only to other components in their managed packages.
This update resolves an issue where flows don’t respect the public access modifiers for legacy Apex actions. The issue affects only legacy Apex actions that reference Apex classes installed from managed packages.
Legacy Apex actions were formerly known as Apex plug-ins. When you define an Apex class that implements the Process.Plugin interface in your org, it’s available in Flow Builder as a legacy Apex action.
How do I know if my org is affected? For each legacy Apex Class implementing the Process.Plugin interface, you’ll need to review if the Apex Class is public or global and if it is part of a managed package. If the Class is not part of a managed package, it can be ignored. If the Class is global and the describe and invoke methods are global, it can be ignored. If it is Public, or global with public describe or invoke methods, and part of a managed package, you’ll need to find out if it is used in any flows.
One way to find these legacy actions is to search your org metadata files using the Developer Console.
- In the Developer Console, in the Edit Menu, click “Search in Files”.
- Search Process.Plugin using the UI that pops up. You can also search for “implements” if too many results are returned with “Process.Plugin”.
- Select a result and click “Open Selection” to open the Apex class that contains the interface. You can get more information about the class and managed packages in Salesforce if you open the Apex Class in Setup.
- Review.
In Flows, you’ll need to look for Apex Action (Legacy) elements implementing the public actions from managed packages.
How do I fix my flows that are using Legacy Apex Actions from Managed Packages? If the flow is in the same namespace as the global action it can be ignored. Otherwise, you’ll have to rebuild your flow with another action. There is no workaround, these will fail.
What happens if I do nothing? If you were using Legacy Apex Actions from Managed Packages in your flows, those flows will be broken and you’ll have to rebuild them. No ifs, ands, or buts about it.
Require Permission to View Record Names in Lookup Fields
What’s Changing? This release update restricts who can view record names in lookup fields. Users must have read access to these records or the View All Lookup Record Names permission to view this data. This release update also applies to system fields, such as Created By and Last Modified By.
How do I know if my org is affected? This update will affect the following customizations if a User does not have Read access to the records in the lookup fields or the View All Lookup Record Names permission on their Profile or an assigned Permission Set:
- Page Layouts, simple enough – they’ll be able to see the label for the lookup field, but no data.
- List Views
- Related Lists
- Reports
- Apex Classes / Triggers / Visualforce / Lightning Pages / Components / Etc
- Flows
- Processes
- Workflows
- And any other type of metadata that allows the User to “see” a lookup field, e.g. merge fields
The most straightforward path to identifying issues is to perform regression testing as each user type / audience in your org following their day-to-day processes and identifying gaps.
Alternatively, you can review object-level, field-level, and record-level security surrounding lookup relationship fields and make assessments as to what should be visible and to whom.
How do I fix the gaps? After identifying which users, profiles, and permission sets should be able to see Lookup Record Names, you can resolve the gaps in the following ways:
- Enable the View All Lookup Record Name permission for any profile or permission set where ALL Users assigned should be able to see ALL Lookup Record Names regardless of access to that record’s data. This is recommended only for highly privileged users.
- Grant Read access to the Object for Profiles and Permission Sets.
- Create Sharing rules to grant Read access to the record in the Lookup field.
- Grant Read access in Field-Level Security and field accessibility on page layouts.
What happens if I do nothing? This may seem trivial, but trust me, it will break your customizations. Queries, formulas, merge fields, the list goes on …, all broken if dependent on data in lookup fields to which users don’t have access. This is, in my opinion, the most important update to review.
Require User Permission for the Send Custom Notification Action
What’s Changing? This update enforces the Send Custom Notifications user permission on the Send Custom Notification action in flows that run in user context, REST API calls, and Apex callouts. A user must have the Send Custom Notifications user permission to trigger the Send Custom Notification action. You can limit custom notifications to desired users and use cases.
A user can trigger the Send Custom Notification action in a process or a flow that runs in system context regardless of the Send Custom Notifications user permission.
How do I know if my org is affected? Because most flows, REST API calls, and Apex callouts that trigger the REST API run in user context by default, they enforce the running user’s permissions.
In Flow,
- Open the Flow’s properties
- Click “Show Advanced”,
- And review How to Run the Flow. If that setting is set to “User or System Context–Depends on How Flow is Launched”, or the setting is empty (by default it is dependent on how the flow is launched), then you’ll need to keep going. Otherwise the Flow can be ignored.
- Review all actions in the Flow, any actions using the “Send Custom Notification” core action will be affected.
For all API Integrations, check if they’re using the standard actions API endpoint /vXX.X/actions/standard/customNotificationAction. This runs in user mode and will need to be updated.
For Custom Apex webservice classes, if they use custom notifications, check if they are set to with, without, or use implicit sharing.
How do I fix my custom notification failures? Depending on your specific needs, you can perform the following to resolve your issues:
- Change flow context to run in System Context.
- Grant the User(s) that will be triggering the notification(s) the Send Custom Notification user permission.
- Update any API Integrations using the standard action API endpoint for customNotificationAction.
- Update sharing modifier on Apex webservice classes using custom notifications.
What happens if I do nothing? Your notifications are gonna break. You’ll have to decide between granular security at the user level and underwhelming security running the flow in system context. I’d recommend the former.
Require Verification When External Users Change Their Email Address
What’s Changing? This security update requires external users to confirm their community email address changes.
When an external user changes an email address, an email is sent to the new address for confirmation. After the user clicks the confirmation link in the message, the address change takes effect.
This update automatically enables the Require email confirmations for email address changes (applies to external users in Lightning Communities) setting in all orgs. With this setting enabled, email confirmations automatically occur.
Customers can opt out by disabling this setting.
How do I know if my org is affected? Do you have a Community? If yes, you are affected.
How do I fix this if I do not want my Community Users to verify their Email address when it is changed? While I do not recommend allowing external users to change their email address without verifying the change, you can disable Require email confirmations for email address changes (applies to external users in Lightning Communities) setting in all of your orgs after Spring ‘21 is released.
What happens if I do nothing? This will be enforced, your community users will have to verify email address changes. That’s a good thing.
Transition to new Bot Options Menu Behavior
What’s Changing? This update removes the default Transfer to Agent option shown in the Chat Window when no dialog has been configured to be displayed in Bot Options Menu and removes the Bot Options Menu preference. This preference will be removed and the menu items displayed will only contain dialogs enabled for the footer menu for the current active Bot Version.
This update ensures a consistent experience with your Bot as end users cannot trigger a direct Transfer to Agent action from the Chat Window, potentially by-passing any custom dialogs configured to handle transfer to agent scenarios.
How do I know if my org is affected? If you have enabled the Bot Options Menu in Einstein for Service, but have not assigned Dialogs, “Transfer to Agent” will no longer be available by default, you’ll have to add the Transfer to Agent dialog to the Bot Options Menu.
How do I fix my Chatbot? Add dialogs to your Bot Options Menu, at a minimum add the “Transfer to Agent” dialog so your customers have an action to take.
What happens if I do nothing? Your customers may have a bad experience when interacting with your Chatbots. They will not be able to transfer their session to an Agent and may not be able to take any action at all, depending on your configurations.
Additional previously announced updates that will be enforced in Spring ‘21…
- Use with sharing for @AuraEnabled Apex Controllers with Implicit Sharing (Update, Enforced)
- Prevent Creation of Function Expressions in Dynamically Created Aura Components (Update, Enforced)
- Disable Rendering of HTML in Custom Fields Labels (Update, Enforced)
