I feel like this should be a function of the entity’s context, not of their type.
I.e. Employee Candidate, Sales Lead, Employee, Customer are all people.
Notion allows something like this: I could have them all in a People table.
Then I could create Candidates, Leads, Customers linked tables, all showing a filtered subset of people with only the relevant properties. (It’s messy in other respects though.)
Maybe Properties should belong to Collections.
Membership of a collection is defined in terms of a filter on properties.
Entities in the People table get all the associated properties, and filter properties default to filter values, e.g. "Is ~= Person".
This table would have fields like FirstName, LastName.
The Employees table should be able to add and remove (hide) properties. Properties added in a linked table are hidden by default in any other related tables.
The filter for this table would be "Is ~= Employee", so when I add entities from the People collections to the Employees collection, they would have Is = [Person, Employee].
All the properties of matching entities would show up on the collection, and irrelevant ones can then be hidden.
This table would add a reference to entities in the Teams collection (e.g. entities that match "Is ~= Team"), so now they have FirstName, LastName, Teams.
Then I’d like to create a Fibery members collection, which filters to Is ~= Member; Can ~= LogIn, where Can is a reference to a behaviour. Behaviours extend entity capabilities, and include e.g. log in to Fibery, sync with GitHub, sync with Intercom, etc. Entities in this collection have
FirstName, LastName, Teams, LoginName, Password, …
What I’m driving at is to break the strong coupling between entities and types, and rather have an entity gather properties and behaviours from the collections that it’s part of. The goal is to make entities far more malleable.