Product bindings

One object, many contexts, one weight

Core, from day one

What it gives you

A binding is the record that ties an object to a specific product entity: a deal, a ticket, an invoice. The unit of holding is the binding, not the product: five attachments from one product make five holders. A binding carries three independent attributes: a version pin, visibility in storage listings and the billing class.

How it works

  • version_pin fixes a specific version when the entity needs exactly that one
  • visibility keeps a technical attachment out of storage listings but never replaces permissions
  • billing_class separates user storage from system storage
  • unlink is addressed and idempotent: it removes one binding by binding_id

Limitations

  • Hiding an attachment from listings does not restrict access: a file you have permissions for opens by its file_id
  • When a product is disconnected, its bindings lose their owner and the link back into the entity stops working

Which plan includes it

Platform

The feature is included in this plan and in every plan above it.

Compare plans

Frequently asked questions

How much space does a file bound to five deals take?

As much as one file. Five bindings are five holders of one object, and the weight of the object is counted in the quota once.

What happens to a file when a deal card is deleted?

Only the bindings of that deal are removed. If the file has other holders, it stays. If no holders remain, the file goes to the trash and is erased only after the trash period ends.

Can an entity keep a specific version of a file?

Yes. A binding can pin a version through version_pin, so a signed document stays bound to the version that carries the signature. Without a pin the binding points to the current version.

Scenarios that use this feature

Related features

All features