[UX/UI/Bug] Fields - Relations - Entity creation flow (with formula-generated name) from inside relation field

Background

The entity creation flow when the resulting entity’s name field is generated via formula still has issues, part of which were discussed here, here and fixed below:

Outstanding issues:

  1. From inside relation field: While the fix has seriously improved the creation UI in the global search results screen and the table view, it has not fixed the problem in the creation UI inside relation fields, as seen below.
  2. Inconsistent access to user input in automation rule: Since the creation still tries to set the Name field, as a temporary patch, we have tried using on-create rules on the link destination entities to take the incoming Name form the user’s input and move it into the pertinent text fields (the second column in the video). But as the second half of the video shows, this [Step 1].Name (expectedly-so) sometimes has already been replaced by the formula and sometimes not, which results in inconsistent data and UX.

Use cases

For on-the-fly creation of related entities

  • When scheduling/reviewing a meeting, to create missing participants.
  • When creating a deal, to create the related company if new.
  • When creating/viewing an entity, to create missing tags.
  • When viewing an entity, to log a new expense.
  • When planning a route, to create new locations.
  • When writing meeting notes, to create new action items.
  • When viewing an event, to create the reservations of the venue and other resources
  • When creating an order, to create the related customer if new.

For formula-generated Name field:

While not using a formula-generated Name field woudl solve the issue, there are many legitimate UX gains from its use. In fact , the lack of a formula-based label/name/title is one (among many) of the main problems of Monday and Clickup for us.

  • Participant: avoids ambiguous names by combining person and context: [{Type}] {First Name} {Last Name} @ {Organization} as {Role}
  • Company: clarifies hierarchy and location in multi-entity setups: [{Type}] {Parent Company} with {Subsidiary Count} subs [{Country Code}]
  • Tag: clarifies grouping, shows usage, and encourages normalization: [{Group}] {Reference Count}x {Raw Name (normalized)}
  • Location: ensures precise identification and prevents double-bookings: {Room} – {Venue}, {City}
  • Action Item: shows accountability and allows for quick subject-less tasks: {Owner Last Name}: {Description (first 30 chars)}
  • Team Member: provides uniform roster display and grouping by department: {Last Name}, {First Name} [{Department}/{Role}]
  • Customer: prevents misrouting by binding orders to both company and person: {Company} – {Contact First Name} {Contact Last Name}
  • Topic: preserves taxonomy and consistent navigation: {Category} > {Parent Topic} > {Subtopic}

FYI
This is a side-effect of the fact that automation rules and formula calculation are asynchronous services and therefore there is non-determinism when it comes to whether the formula calculation has taken effect at the time the rule runs.
See here.
So this it not a bug, per se.
But as you say, the entity creation UX via relation fields is different to what it is for entities created in other ways, so there’s room for improvement.

Hi @Chr1sG,

Thanks for responding so quickly. That is what I figured, which is why I said “expectedly-so” :blush:.

But as for the main issue, I agree that it is not a bug, but more of a UX issue. However, since you have gracefully fixed it in other places such as the global search results screen, it would be great if at least you stored the user input in such cases, into a field that is either determined by the admin or is simply a system (yet accessible) field. That way, we can decide to base formulas or automations on it or not.

This would also open the way to more creative things such as:

  • allowing the parsing of user input for natural language entity creation, e.g. by passing the input to an AI agent to get back structured output matching the table’s field.
  • allowing association attributes of M2M join tables (which I believe you refer to as helper databases) to be set upon creation thorugh parsing for example “Category: Task name @ Priority” to be parsed into three columns.

I am getting carried away :smile:, but as a start it would be wonderful to not discard the user input.