Automated Entity Conversion via Rules & Buttons

[jonas]

Complement for this feature: Fibery

---

I used ClickUp and am migrating to Fibery, a feature I used a lot was to change a task from one database to another, for example, in our creative process in ClickUp we used 3 databases, planning, copywriting and video & design, and the task was floating between these databases, I tried to replicate it in Fibery, but the lack of automation to change the task automatically from one database to another makes it almost unfeasible to always have to do it manually.

Problem

Currently, converting entities from one database to another (e.g., converting a Feature to a Bug) can only be done manually through the entity view:

• Go to Entity View → click “…” → select “Convert To…”

• Select target database manually

• Process happens one entity at a time

This creates friction for workflows where entity conversion should happen automatically based on specific triggers or conditions.

Proposed Solution

Add automated entity conversion capabilities through:

1. Automation Rules

Enable entity conversion as an Action in Rules:

WHEN: [Trigger conditions]
THEN: Convert entity to [Target Database]

Example use cases:

• WHEN Feature.State = "Won't Fix" THEN Convert to Ideas database

• WHEN Bug.Severity = "Enhancement" THEN Convert to Feature database

• WHEN Idea.State = "Approved" THEN Convert to Task database

2. Action Buttons

Add conversion as a custom button action in views:

• Bulk convert multiple selected entities

• One-click conversion with pre-defined target database

• Conditional buttons (only show when criteria met)

Benefits

• Workflow automation: No manual intervention needed for routine conversions

• Bulk operations: Convert multiple entities simultaneously

• Consistency: Reduce human error in classification

• Efficiency: Save time on repetitive reclassification tasks

• Better data governance: Automatic entity lifecycle management

Example In ClickUp

Implementation Suggestions

• Maintain current behavior: original entity deleted, data preserved

• Add conversion history/audit trail

• Support conditional conversion (with filters/formulas)

• Include conversion in API for external automation

• Allow mapping of fields between source/target databases

• PS: ClickUp has a similar automation for changing a task from one database to another that works extremely well and can be used as inspiration.

Current Workaround

Right now, teams have to either:

1. Manually convert entities one by one

2. Create duplicate entities in target database + delete originals

This feature would make Fibery much more powerful for teams managing complex entity lifecycles and classifications.

[Chr1sG]

You can in fact select a batch of entities and convert them in bulk.

[jonas]

Yes, I realized this shortly after making the post, but even so I still think automation is much more valuable, in the ClickUp that I previously used, I basically used this feature in almost all processes.

[RonMakesSystems]

If it is a work flow that repeats itself, you can:

1. Make a relation from the original database to the converted database
2. Make an automation that “Adds” an new item into that relation, map the fields manually to each other
3. Delete original entity at the end of the automation run.

Kind of like a manual “Convert”. I personally perfer this in the long term as you don’t depend on having the exact same field names for a successful conversion.

[jonas]

Thank you for your idea and help, but unfortunately I don’t think it works for me. As you can see, there are several fields that can’t be mapped, and for me, it’s essential to keep data from comments, files, and especially documents.

Available fields to map:

All fields in both test databases.

I tried to generate a script with Fibery’s AI, but it always gives an error when cloning the comments and documents.

[RonMakesSystems]

I see…

1. Files will be updated soon to allow automations like these
2. If you changed from using the Documents field, and made a database called “Document” with a relation to that database. It allows for more flexibility and solves this issue
3. Comments: Yeah…this is tricky. Might possible to solve with the same as before, a database called “Comment” and a relation. But then the UX won’t be as good ://

In general, I do agree that “Convert Entity” could be a nice addition to automations. Suggesting some solutions that could solve it with the current tools.

[mdubakov]

It would be great to know why you need this? Why overall convert things this way? What problem you are trying to solve? Fibery is not clickup and some patterns that make sense for Clickup will not be good for Fibery.

[jonas]

We are an ecommerce and marketing holding company. I’ve structured our workflow this way because I learned it from a mentor who believed in organizing everything through lists in ClickUp. His philosophy was simple: One List = One Process.

If you’re curious about its content, but I don’t think you’ll understand much since it’s in Portuguese https://www.instagram.com/jp.asv/

For example, when creating an ad, we follow several processes in a folder called “Content Production”, and this folder would contain some lists, and the task would float within those lists, for example:

1. Ideas
2. Planning
3. Copy
4. Design & Editing
5. Posting, etc.

Each process was a separate list. A designer, for instance, didn’t need access to the Planning list. Every list had its own statuses (To Do, In Progress, Waiting for Approval, etc.). Almost every creative request went through these lists, whether it was an ad, a sales page, or an email marketing campaign, all followed the same workflow in the same folder.

I’ve already adapted most of this system in Fibery. I added a field called Stage, and whenever the Stage changes, the State resets to “To Do” and assignee automatically changes to the next responsible person.

But some parts still require manual work, for instance, when I need to move an ad from the “content production” database to the ad testing database, which has additional fields like performance metrics, test start date, and campaign relations. The same happens when I move a landing page task to the pages performance database.

I used this structure in ClickUp to avoid repeating similar processes and to keep everything centralized in a few lists. I think my explanation wasn’t very easy to understand.

I understand that Fibery works differently from ClickUp, and honestly, I’m really enjoying it. I chose Fibery mainly because of the Convert Entity feature. The lack of this automation has been a small obstacle, but overall I’ve managed to adapt quite well, especially by using different views for each stage. In some cases, it’s even easier than ClickUp, I just apply a different filter and keep everything within a single database.

[Chr1sG]

@jonas

But some parts still require manual work, for instance, when I need to move an ad from the “content production” database to the ad testing database, which has additional fields like performance metrics, test start date, and campaign relations. The same happens when I move a landing page task to the pages performance database.

Sounds like a perfect use case for a single database with multiple entity views, and then use rules (based on State) to pick the appropriate view at each stage in the entity’s lifecycle.