SynchronousChannel.Reservations Interface @beta
Interface used to reserve elements with shared identities as part of coordinating simultaneous edits from multiple briefcases. Unlike locks (via LockControl), which block users from making conflicting changes to existing elements, reservations can be used to communicate "in-flight" changes between briefcases, allowing users to concurrently add and use identical dependencies (e.g., component definitions, schemas, etc.) without introducing conflicts.
@note A reserved element is a shared element: every briefcase that inserts it must insert the exact same element. The reservation assigns a single shared ElementId that all briefcases use, and when multiple briefcases push their inserts they are merged together as one row rather than producing a conflict. Because these duplicate inserts are silently collapsed, the property values written by each briefcase are not reconciled — if two briefcases insert the same reserved element with different contents, one briefcase's values win arbitrarily and the other's changes will be lost. Callers are therefore responsible for ensuring that every insert of a given reserved element has the same property values across all briefcases. Only use reservations for content that is deterministically identical everywhere.
@see reservations to access the reservations for an iModel.
Methods
| Name | Description | |
|---|---|---|
| needsElementReservation(federationGuid: string): boolean | Determine whether an ID has already been reserved for a future element with the given federationGuid. | |
| reserveElements(args: SynchronousChannel.ReserveElementsArgs): Promise<void> | Acquire reservations for one or more elements from the reservation service, if required and not already reserved by another user. |
Defined in
Last Updated: 03 September, 2026