[DONE] Convert entities of one Type to another Type

[B_Sp]

Hi again,

I was wondering about what might be a common situation with teams onboarding into Fibery, that I will for sure have:

I’d like to first start “potential” entities in a flow - things like “employee candidate” or “Sales lead,” then as they get converted to “employee” or “Customer,” not lose the whole activity that has accumulated in the entity up till then. It strikes me that creating a related entity, so say a new entity of “customer” is created with the “sales lead” is closed, is a bit of a workaround. I think ideally it would be great if you had a chance to “promote” or “convert” and entity from one type to another, and what would really be useful is to leave the original entity type visible in the comments field, or via some other message, so every user could see that this entity was originally another entity type as it moves around Fibery.

Eager to get your guys’ thoughts on this. If this is a feature in the works, all the better!

[mdubakov]

Indeed the best solution is to implement Convert action that will preserve all possible fields and somehow aggregate data from missing fields into text that will be attached to entity.

[B_Sp]

Hey @mdubakov, great to hear back from you as always.

Glad to see you think this is at least a sensible approach! If you guys made progress on this feature, it would be another of your truly unique ones. I do not know of any app out there that can handle this need effectively. Converting task to Project is a hugely requested, and ignored, feature in Wrike’s community. Asana has a meek “create follow on task” that simply create a link between the tasks in comments, but it’s not a reciprocal link. In Jira, you can move an issue to another project, with absolutely no traceability. If you are converting in Aha! from anything but an “idea,” there is zero reference to the original entity. Etc., etc. But the way you have Fibery set up that entities can be literally anything, you add a huge level of usefulness if you add some traceability when this conversion is performed. Idea -> Release. Candidate -> Employee. Decision (yes I think this is a good Type) -> Action.

I am already starting to get excited envisioning about where you guys will be in 6 months, 2 yrs, and so on. You have a truly visionary idea of a “True North” app the market needs, and unlike the other generic “no code” stuff out there, you guys are building for a start-up, and one that does software in particular, so all the more attractive for me, and I’m sure legions of others. I’m sure Fibery could plan my potluck dinner, or manage my fitness goals, like Notion, Airtable, Coda, etc., but the big decider for me, which is why I am still investing time with you guys, is you are doing nocode with the tech start-up user type in mind (all the stuff you have on the burnout page right now).

Can’t say how excited I am about your prospects. And thanks again for this response.

[AndreasHe]

Need this also! For example:

issue->bug->task

[jean1]

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.

[Chr1sG]

It sounds like a lot of what you’re asking for is already possible, unless I’m missing something.

@jean1

The Employees table should be able to add and remove (hide) properties.

This sounds like just creating a table of People entities, with the relevant filters applied (and only showing the relevant columns) and calling that table ‘Employees’.

Also, it sounds as though you’re assuming that all entities are included in one or more collections, but that may not always be the case (assuming you mean collections to mean a …-to-many relation).

Having said that, I think there might be a benefit to having ‘subtypes’, each of which defines a specific subset of fields from the main type that are to be visible/editable.
It means that a ‘person’ type can have a load of fields, and yet the ‘customer’ subtype includes the ‘orders’ collections field but not the ‘training’ field. The ‘employee’ subtype vice versa. Both subtypes have the ‘email’ field.
This could help with field proliferation in the entity card view.

[Oshyan]

Based on their recent Fibery vision article, they definitely want to support better handling of free-form data and data “evolution” between unstructured and structured (and steps in-between). I am not sure I attach to any specific idea of how that would best work as yet, but I trust the team to find good solutions at least as well as - and probably better than - most others in the space, e.g. Notion. But it will take time, and no one has yet succeeded in creating this kind of flexibility and adaptability in an intuitive way. So… we’ll see…

[mdubakov]

Your ideas are interesting, but that is not how Fibery is designed. We rely on Type system and Type defines the entity structure. The Human problem can be solved via inheritance, but so far we are reluctant to add Types inheritance since it will increase complexity.

However, we do have a concept of Extensions (it is there, but underdeveloped). In our vision Extension is a group of Fields + UI + Behaviors that can enhance Types. Our Extension is somewhat similar to your Collection idea to some degree, so you’ll be able to augment Types with some additional meaning. For example, there may be Time Tracking extension, when you add it you have several fields for time tracking and a UI to start/stop the timer.

Overall compatibility is a hard problem even in software development. Dynamic composition is more flexible, but more fragile as well, so we are thinking how to provide it and keep your domain stable.

[Chr1sG]

@mdubakov

we do have a concept of Extensions (it is there, but underdeveloped). In our vision Extension is a group of Fields + UI + Behaviors that can enhance Types

Sounds excellent assuming that the extensions can be created/configured by users.

[Polina_Zenevich]

Hi all!
Glad to inform, that this request is ready

CHANGELOG: April 8 / Convert entities to another Type, Zendesk integration, Schema changes in Audit Log

Convert Entities to another Type Sometimes you need to convert Bug to User Story, User Story to Feature, Issue to Task, etc. Finally, you can do it via Convert action. [2021-04-08 15.39.11] Convert action is available from several places, like Entity View, Board View, Table View, etc. Here is the video that explains Convert action in some details. Notes: Original entity is not deleted after convert action, you can delete it manually if needed. Content is copied from the origina…

You can check details of how it works in our Changelog

[JMaynier]

Your concept of Extension seems similar to trait vs inheritance in programing language. You can have multiple trait on one class, but usually only inherit from 1 class (not true in all languages).
In Fibery case, if I create an extension “Person” with basic fields like firstname, lastname, a relation to a Messages entity, etc. Now if I add this extension to multiple Entities (“Employees”, “Supplier contact”, “Users”) can I refer to them also as a Person type ?
It works in the case where my “Persons” could be a partitions of Employees", “Supplier contact”, “Users”. But if in my model, an Employee could also be User of our app, how can I represent that?
Ideally we woud like to do the opposite, have an entity Person with the basic required fields. Then create entity/extension to specify types of Persons, and when we create a new Person being able to decide if it pertains to also one or multiple sub types, or add a subtypes later to it. In a sense extension should not only be used as a generic component reusable when defining new Entities, it should also be usable as type in relation, like an interface/trait is used in a programming language.