Sales requests group private-site linking in Delivery lesson-site create
Why
Sales is adding V1 parent lead groups for the case where multiple parents coordinate through one shared message thread and one shared pool or address. The Sales UI treats that group as one scheduling work item, then dissolves it after booking so each Lead and Person continues through onboarding independently.
The shared private-site case needs one Delivery lesson site created for the house owner, with the other scheduled member Person IDs linked to that same site. Without that link, Sales can reserve and hold each member's lesson, but operators still have to repair private-site access one parent at a time.
What
Sales has added an optional client-side field named additional_person_ids on the Delivery lesson-site create request shape it sends through POST /delivery/v1/lesson-sites. The intended semantics are:
person_idremains the owner or primary site Person.additional_person_idsis a list of other Person IDs that should be linked to the created private site at create time.- Delivery returns the normal lesson-site response, with
linked_person_idsincluding the owner and any successfully linked additional Persons. - If Delivery needs review or approval before linking a Person, Sales can accept an explicit validation or pending status rather than inferring success.
Sales will only require a house owner when booking a new private shared site. Existing lesson_site_id reuse does not require this new field.
Asks
Please confirm whether Delivery can accept additional_person_ids on lesson-site create, or name the preferred API shape if the link operation should stay separate.
Sales can keep the field dormant until Delivery confirms the contract. The Sales V1 group ledger will still work without it, but the private shared-site path stays higher friction.
References
- ADR-0025 Person-keyed pre-handoff reservation context.
- Sales implementation path:
modules/lead-groups/. - Delivery surface referenced by Sales today:
POST /delivery/v1/lesson-sites.