Vendor Access Capability Guide

vendor_access is a product-level capability layered on top of the existing actor, permissions, timeline, seating, assets, and communications foundations.

It decides whether an occasion is allowed to expose vendor-oriented product behavior such as:

• the vendor portal and vendor workflow routes
• planner-side vendor coordination flows
• vendor-scoped operational surfaces built on timeline, seating, assets, and communications
• external vendor participation as a first-class product experience

What it does not replace

vendor_access does not replace the actor model or the permissions system.

• vendors are still modeled as actors
• user-to-actor linkage still determines who resolves into vendor context
• permissions still decide which events, timeline items, seating plans, assets, and updates a specific vendor can see

The capability answers whether vendor participation is part of the product experience for the occasion at all. Permissions answer what a specific vendor can do inside that enabled experience.

Enabled behavior

When vendor_access is enabled:

• vendor portal routes are available
• vendor workflow APIs can be used
• planners can create and maintain vendor actors as active product entities
• planner workflow guidance includes vendor handoff and vendor coordination steps

Disabled behavior

When vendor_access is disabled:

• vendor actors may still exist as data
• planner reads can still surface existing vendor records for reference and compatibility
• vendor portal workflow routes are blocked at the backend
• planner-side vendor-management mutations are blocked
• planner and vendor UI surfaces show explicit capability state instead of implying the feature is available

Planner behavior

• the actor workspace stays readable, but vendor creation/editing is constrained when the capability is absent
• the planner workflow hub blocks the vendor handoff section when vendor participation is not enabled
• vendor-specific setup should be treated as unavailable product scope, not as a permissions problem

Vendor app behavior

• vendor sessions still resolve through actor links
• the vendor app can inspect occasion capability state without opening operational workflow routes
• if the capability is absent for the current occasion, the app shows a clear unavailable state and disables vendor navigation

Packaging implications

vendor_access currently resolves from the collaboration-oriented billing entitlement feature.multi_user_support.

That keeps the capability model clean for later packaging work:

• billing can continue mapping entitlements into capabilities centrally
• future plan design can split or bundle vendor participation differently without rewriting vendor routes
• later admin or debugging surfaces can inspect a real capability instead of reverse-engineering plan names