Discussion: Segment, Type, List

[FelixMalfait]

Not ready for implementation, only for discussion

A frequent use-case in CRM is having different type of stakeholders you interact with.
For example, you might want to use the CRM not just to track clients, but also have your B2B partners / affiliate if you have a distribution model where you sell through partnerships.
There are different ways we could go to tackle this and that we'll explore in this issue.
Let's assume

Lists

Usage

You add an object to a list by dragging it in the sidebar, or by adding in the "Lists column" (similar to a tags column)

Backend

In the database, a list is very similar to a custom object that has a foreign key pointing to the parent object, and it's own set of fields.

Pros

• One object can belong to several lists
• List fields are isolated and don't pollute the main object

Cons

• You can't view list fields in the main object's list view
• You can't as easily set a different layout for the show page based on the list on object belongsTo
• If a field belongs to the standard object (e.g. Revenue), you can't display it conditionally based on the list it belongs to. It will be visible to all objects, regardless of the list they belong to.

Segments

Usage

This would me mostly driven from the admin panel.
I can create complex queries such as "all person that are below 18 years or (that are over 50 and have the tag "random")"
Then those segments become visible in the sidebar.

Backend

There are different ways we could achieve this on the backend:

• creating an SQL VIEW and a new object in the metadata layer
• modifying the metadata layer to introduce the concept of (1) parent objects and (2) default filters

Pros

• Very powerful as segments can be changed and adapted dynamically
• One

Cons

• Requires creating "type" or some sort of enum column separately, so might not be intuitive

Types

Usage

Drag and drop in sidebar or select type in dropdown.

Backend

Add a new enum column "type" on each object

Pros

• Since one object belongs to one type, we can customize the layout/behavior more easily

Cons

• One object only belongs to one type

Other

Note we already have 2 concepts to achieve similar goals:
(1) creating a view
(2) creating a custom object with a relationship pointing to the parent

But (1) also involves sorting, defining the visible columns, ordering the columns, and is not displayed in the sidebar.
And (2) is a little complex and it's worth overfitting this particular problem to do some specific UI changes (e.g. display in sidebar, display the parent object as a fixed first column etc)

[FelixMalfait]

Conclusion:

• Type -> to implement first
• Segment ~ Views -> we can improve view filters to make them closer to segments
• List -> complementary use-case (statically defined), could be supported by purposely built object: opportunities, campaigns standard object, etc.