In Salesforce, all the standard and custom objects have three character prefixes. They form the first part of the Record Id. For example, an Account record with Id 0010Y00000WgxK1QAJ has the prefix 001, which is the prefix for the Account object. It means that all the Account records in the system have Id values starting with 001. Standard objects always have the same record Id prefix, no matter which environment it is. Therefore, Account records in my Salesforce environment and Account records in your Salesforce environment always start with 001. Here is a table that shows the Id prefix values for some standard objects. Read this post on Salesforce Ben in order to see the Id prefix values for the other standard objects.
| Object | ID PREFIX |
|---|---|
| Account | 001 |
| Case | 500 |
| Contact | 003 |
| Lead | 00Q |
| Opportunity | 006 |
| User | 005 |
It is not possible to know the Id prefix value of a custom object from the beginning. First, you have to create the object, then you will see the prefix that Salesforce created for the object. Moreover, the record Id prefix of the same object can be different in a sandbox and production environment. Therefore, you may not create this kind of Id prefix table for custom objects.
Perform Different Actions for Different Objects in the Same Flow
There are many scenarios where you will need to perform different actions for different objects. For example, if the task is related to an account, you will perform series of actions. However, if the task is related to a custom object, it will perform another series of actions. Another example is using the same Screen Flow on different objects. In these cases, you can use a decision element to check the first three characters of the text variable that stores the record Id. It is easy to build this decision for the standard objects. Even though I don't like hardcoding anything, you can just put the hardcoded prefix values for the standard objects. They will be the same in every environment, so there is nothing to worry about.
In the example below, there is a Screen Flow that creates a Case record. There is a decision element at the beginning, which enables the flow to work on Account and Contact objects. Therefore, the same flow can be used for these two objects.
As I mentioned before, since the decision element is for standard objects, it is possible to hardcode the Id prefix values.
However, if it was for a custom object, I wouldn't recommend you to put hardcoded Id prefix values. Because it would be harder to maintain the values, since they might be different in other environments. So, what is the recommended solution? Well, it is possible to find the object name from the Id prefix.
According to this article from Salesforce, you can execute the following snippet of code in the Developer Console in order to find the Object name based on the Record Id prefix:
String objectName = SchemaGlobalDescribe. findObjectNameFromRecordIdPrefix('500'); System. debug(objectName);
However, there is an easier way to do this in Flow Builder.
"EntityDefinition" table stores the object names and their Id prefix values. In order to find the object name, add a Get Records element to the flow and get the record according to first 3 characters of the record Id.
Record-Triggered Flow That Performs Different Actions for Different Parent Objects
Let's build a flow on the task object. It will run when the status becomes Completed and it will perform different actions based on the parent object type. As you know, task can be related to many objects through the Related To (WhatId) field. Therefore, you really need to check which object it is related to.
Since the flow will run automatically, it should be a record-triggered flow. If you don't know what record-triggered flow is, you can read this post to learn more about the flow types.
1- Create a new record-triggered flow on the Task object. Let's make it work only when the Status becomes Completed. Lastly, select "Actions and Related Records" in order to make it work after save. This part depends on what you want to perform. In this example, we will perform various actions like sending an email and creating a record, so it must be an after save flow.
2- Create a formula that displays the first 3 characters of the WhatId field of the Task record.
3- Add a Get Records element and get the EntityDefinition record according to the KeyPrefix field.
4- Add a decision element to check the object name. You can use the Label, DeveloperName, or QualifiedApiName (ends with __c for the custom objects) fields.
5- Continue building the flow according to your needs. Add any action that you want for each path. As you can see, the same flow sends an email if the task is related to an opportunity. It updates the status if it is related to an account. If it is related to a custom object called Daily Activity, then it clones the record.
6- After building the flow, it is time to test it. As you can see here, flow found that the task was related to a Daily Activity record. Therefore, it followed the relevant path.
Summary
EntityDefinition table stores the Id prefix and the object details. Instead of using hardcoded Id prefix values in your flow, you can find the object name from the EntityDefinition table. This will let you build smarter and more dynamic flows.
Beneficial content.keep the good work
Great article! For those new to all this (like me), you can recreate the KeyPrefix Entity Definition table in this article by running the following SOQL query in the Dev Console or Workbench: SELECT KeyPrefix, DeveloperName, QualifiedApiName, Label FROM EntityDefinition WHERE KeyPrefix != null ORDER BY DeveloperName
Right!
Neil, by "recreate" do you mean that otherwise the flow will fail? Or do you mean just "to retrieve"?