Two-way multi-reference field?

Design help CMS
1

Hello everyone,

Is multi-reference field two-way, or one way only?

For example, say I have a Teams collection and a Companies collection. The Teams CMS has a multi-reference field linking each Team to one or more companies. Can I then create a collection list for Companies and refer back to the team members that are part of it, or do I also need to create a multi-reference field within the Companies collection?

1 Like
2

For anyone else looking, vote here for this feature: Bi-directional relationship between CMS | Webflow Wishlist

3

@alexdixon this would be a huge improvement- would love to see this in the Next Gen CMS. Today you can achieve this in a limited fashion by using an xref pattern.

  • Movies collection
  • Roles collection ( xref )
  • Actors collection

In this setup Roles has two single-ref fields, one to Movies, one to Actors, and can store additional data, like Awards, Reviews, etc.

The way Webflow’s collection list filtering works, this makes it pretty easy to generate;

  • A list of Actors in each Movie, by Role, and sorted by Role ( Producers at the top, etc. )
  • A list of Movies each Actor has been in, sorted by Year, etc.
4

Thanks for the heads up.

I think I’ve actually implemented a similar setup on a few sites, with “Movies” and “Actors” using single-ref fields to point to the “Roles” collection; however, I’m not sure whether this affects filtering options differently. I assume I did it that way so clients found it easier/less confusing to work with.

I’m hoping that, as the Wishlist item has a “Planned” status, this isn’t too far off from becoming reality. Kind of surprised it was baked in at the foundations – guessing performance limitations.

5

It’s the nature of document-oriented databases MongoDB. Unlike a relational database, it doesn’t inherently have references, so it’s kluged on as “x points to y” with no safety against, e.g. deleting y, managing master-detail datasets, etc.

RDBMS lost some popularity in CMS implementations because they are difficult to scale, difficult to sync for failsafe redundancy, have massive index performance issues.

Even then, the MongoDB-based CMS v1 still had performance and scalability issues that e.g. capped us at 5 nested items in collection lists, 1 nested list per page, etc.

I’m uncertain what NextGen is based on, but I think it’s problems like this that went into the rethink. I would love to see 2-way refs and master detail structures ( delete the master, detail items are nuked as well ). I find it much easier to build and admin on a relational framework.

1 Like
6

Ah, that’s interesting to know. I hadn’t actually looked into the tech stack; I assumed much of it was a proprietary backend.

As you say, hopefully NextGen will remove these types of technical constraints and massively improve the backend workflow. Although any public information on it at the moment seems vague.