I’ve seen a lot of FUD around the new MFA requirements from Salesforce. Understandable, given there are many people tasked with managing this who do not have experience in managing it.
One common question is around API integrations and how to do MFA. While this can (and in some situations, should) be done, it is not required.
There are several user types, including API/integration, automated testing, and RPA accounts, that aren’t required to use MFA. We’re currently working on plans for how customers can exclude these types of users from future auto-enablement and enforcement milestones. We’ll update this FAQ and your products’ documentation when more information is available.
So, in conclusion just set it up with a Salesforce Platform User License, generate a token for that user, then use the APIs to login or login with username and Password+security token, depending on the application.
I don’t know why the process to permanently delete objects from Salesforce was hard for me to find today (was looking for a link to send to someone on Trailhead) but I did not find any succinct answer before my AADD kicked in, so here are the steps:
Switch to Classic mode
Go to Setup, then Custom Objects (search for Objects or scroll to Build > Create > Objects)
At the bottom of the list there will be Deleted Objects (#) if there are any.
From there you can permanently delete them before they go away on their own after 15 days.
Here is a question I see frequently in the Trailhead Community: How do you re-assign the ownership of objects in bulk? I’m sure there is an app to make this easier, and I suggest you look in the AppExchange if the policy for your org is to use apps first. And I know there are other solutions, this is just one that I find quick and easy because I don’t have to give it too much thought.
First: Always try it in a sandbox first and test the results before doing it in production.
Second first, locate the user id of the person who’s object owners ship you want to change from. From their user page (or just copying the link), grab the object ID from the URL.
Copy Object ID
Now open Salesforce Workbench in another tab, login and navigate to Queries > SOQL queries. If you are adept at SOQL, create a query to pull all of the object you want to re-assign based on the user id. If you are not comfortable writing your own SOQL or just feeling lazy, use Workbench to help create the query:
The key values you want are the object ID and the owner ID, though adding a Name field to check the values can be helpful. Be sure to select View as Bulk CSV then run the query. Save the resulting file. I recommend naming it something that is meaningful to you rather than accepting the long string produced by default. Open in your favorite CSV editor to see the object and owner ids.
Next, get the user ID of the new owner(s) the same way you did for the current owner. In the CSV file, change the OwnerId value as desired.
For safety reasons, delete all columns from the csv file except Id and OwnerId, then save it with a different name as a CSV file.
Back in Workbench, go to Data > Update. Select the object type and click the Choose File button and select the file you just created with the new OwnerId(s), then click Next.
On the mapping screen the values should already be mapped. Check that only the ID and OwnerId are mapped and click the Map Fields button. If there are many records, check the “Process records asynchronously via Bulk API” option on the resulting page then Confirm Update. Note that if rules were changed since the records were created you may have errors that will require fixing the records before they can be updated.
This is the most common question I see about Salesforce Flows, and was one of my first questions, too. To save me looking it up all the time, I’m storing it here on my blog…
Q: How to have a flow go somewhere other than the page it was called from at completion?
For large orgs, Lightning pages are like rabbits: they multiply quickly and most of them look the same unless you are really close. To keep the page population under control, use a unique Developer Name and provide a description of its properties when customizing record pages that will be assigned to anything other than Default.
