Inheritance and entity interfaces

The concept of inheritance in object-oriented design is simple and powerful. Given a certain entity, with associated attributes and business logic, we can define child entities as inheriting from the first one, immediately acquiring the parent's attributes and logic. All the instances (or records) of the child entities also count as instances of the ancestor. Inheritance is key if we want to ensure that our design is dry and sparse, making it easier to maintain and understand.

In Salesforce, any approach that emulates inheritance in our data model will have to leverage record types^[1]. This is the equivalent of grabbing all the logical entities that would inherit from a hypothetical common ancestor and haphazardly smashing them together into the same physical object in the database. This forces a bunch of loosely related entities to share the same set of fields and the same logic layer, and it forces architects, developers and administrators to play a wicked game of Twister every time a feature needs to be added around a franken-object with too many record types or, G-d forbid, when it comes the time to shoehorn a new logical entity onto that table. Record types are hard to manage, a pain to deploy, they are the source of a significant number of record access mishaps, and have been described (see #983) as being the Salesforce data modeling equivalent of glitter — open the flask and you won't be able to fully get rid of it!

Enter entity interfaces

In the fall of 2019, a few days after coming back from Dreamforce, I stumbled upon some backchatter on Twitter about an obscure session that had flown under my radar, partly because I was too worried not to mess up my own session on DevOps, and partly because, if I remember correctly, it was scheduled at the earliest possible time on the last day, right after the Fleetwood Mac concert. The session was titled Entity Interfaces: The Next Generation Of The Salesforce Object Framework, and it had the following abstract (emphasis added):

Salesforce objects are the building blocks of what has made Salesforce the #1 CRM company in the world. These objects are the entities that customers interact with on a daily basis. Entity Interfaces are the next generation of Salesforce Objects. These objects are created to address the challenges that we and customers like you are facing, when managing and interacting with related data in a complex data model. Challenges like: Have you ever needed to get details from multiple objects using a single query? Have you ever desired to bring the concept inheritance to Salesforce objects before? Have you've ever needed to create a UI, build a report or code validation logic agnostically on data from multiple objects? If you have, join this session to learn how we use Entity Interfaces to solve those problems.

A few key ideas about entity interfaces were discussed and demonstrated during the session:

• Entity interfaces would, at least at the beginning, be released to support Salesforce's canonical definition of certain entities, like Orders and Quotes, which can live across multiple objects: standard, external, custom and managed.
• The initial release would include only standard interfaces, not org-specific, custom interfaces.
• The interfaces would be managed through Object Manager, and it would be possible to manage the interface's fields and designate implementors, that is, objects that should inherit from the entity interface. For each implementor, it would be possible to map the interface's fields onto the implementor's.
• It would be possible to define validation rules on the entity interface's fields, and those rules would be enforced for any implementor.
• Entity interfaces could have custom report types built around them, to support enhanced cross-object reporting.

The session also mentioned, albeit more vaguely, different directions that could be included as part of the roadmap for entity interfaces:

• Polymorphism. If we were able to create object relationships that look up to an entity interface, we would be able to use a single lookup field to connect to more than one object type.
• Cascading logic. If we could define record-triggered automations (Apex or Flow) on entity interfaces, we would be able to better structure and maintain our logic.
• CRUD. With the ability to grant users different access permissions at the interface and object level, we would be able to define more granular record and field-level access policies.
• UI. With entity-specific tabs, we would be able to build list views that span multiple implementor objects.

As I see it, it would be in some of the elements of the roadmap where entity interfaces could fully realize their extraordinary potential.

Where could we use interfaces?

Here are three examples from my typical hunting grounds, the financial services domain:

• Sales and production processes. In certain scenarios the sales process is connected to a complex process that needs its own data model to be supported. We see this often in loan origination, insurance policy underwriting or new account onboarding. In these cases, the wiser choice is to decouple Opportunities from the object and associated data model supporting the process, with a loose coupling in the form of syncing towards the Opportunity of the corresponding amount and close date, as well as any relevant events that may inform stage changes. With entity interfaces, the custom object supporting the process could become an Opportunity by implementing the appropriate interface.
• Financial accounts. Financial Services Cloud and nCino have a very different approach to represent financial accounts (e.g. loans, credit cards, checking accounts) in the system. On one hand, nCino has a separate object for each of the types. This provides a higher degree of granularity, which is great to tightly control record access, or to ensure per-object limits are not exceeded, but it limits seriously reporting across account types and it complicates how the many-to-many relationship between clients and accounts are captured. On the other hand, Financial Services Cloud, with a single object for all financial accounts, has no reporting or junction issues, but that single object ends up becoming a monolith with complex visibility and governance rules. With entity interfaces, we could reduce virtually all these sources of friction and embrace the best of both models by ensuring that the account type-specific objects implement the Financial Account interface.
• Side-by-side external data. The ability to use Salesforce Connect and external objects to present records that are stored elsewhere as if they were standard object records would be a decisive step towards streamlining archival strategies and alleviate some of the issues that we may find on the platform when tables become too large.

Will we get to use interfaces?

As of March 2023, entity interfaces do not seem to have inched much closer to becoming generally available than they were over three years ago, not to mention those roadmap features that would make them a real gamechanger. At Dreamforce 2021, at the True to the Core session, one of the product managers was able to confirm that they are used internally. And at Trailblazer DX 2022 it became evident that the pandemic had forced a reformulation of priorities that seemed to accelerate anything related to Flows and automation, while relatively deemphasizing everything else.

After the announcement of Genie, now Data Cloud, at Dreamforce 2022, we could some renewed interest into the feature, to support the canonical entities in Genie's data model. But this is sheer speculation, borderline wishful thinking on my part. It could well be that the type of across-object mapping that we would get with entity interfaces could be regarded as superseded by Data Cloud's aggregation and transformation layer. In my opinion, that would be myopic, because, as evidenced by the product team's ambitous roadmap — as versatile and powerful as Data Cloud is, I am positive that it cannot check all those boxes, because it is not designed to solve for them.

All in all, the jury is still out there. While we wait, consider heading to the IdeaExchange to support entity interfaces as a feature.