Why Boulevard Should Remain the Booking System of Record

Boulevard should remain the booking system of record when it already owns appointment creation, changes, staff workflows, and the underlying customer record. An attribution layer should carry only the approved join data needed for reconciliation. Duplicating booking truth into a second product creates another store, another access model, and another deletion path.

The boundary is practical, not absolute. A booking integration still needs a written field allowlist, tenant approval, access controls, webhook validation, retention rules, and a failure path. Keep outbound advertising sync off until counsel and the tenant approve the exact generic payload.

System of record and data boundary

A system of record owns the authoritative lifecycle. For bookings, that means creating, rescheduling, cancelling, completing, and exporting the appointment through the booking platform. The attribution layer can store an opaque appointment reference, tenant scope, approved campaign join data, outcome status, and an audit reference.

Boulevard’s Developer Portal describes the platform API boundary and access model. Verify the current API and webhook behavior before building against it. A developer portal does not authorize every field for every downstream use.

Boulevard’s Protected Health Information Security Requirements describes provider-specific configuration and coverage conditions. Review the current agreement and tenant configuration. A vendor’s coverage or add-on does not make the integration or application compliant.

The HHS Minimum Necessary Requirement supports a narrow use and disclosure design. It does not identify the exact fields for a particular product. The field allowlist must be approved against the actual purpose.

For minimum fields, read minimum necessary booking integration fields. For opaque outcome linkage, read appointment ID attribution without record copies.

Minimum necessary fields and workflow

Keep the inbound and outbound field sets separate. Inbound reconciliation may need an appointment reference, tenant identifier, status, event timestamp, and an approved value. It may also need a webhook event identifier and signature metadata. Store only the field groups needed for the workflow.

Field group	Purpose	Default treatment
Opaque appointment reference	Match outcome to booking source	Allowed only for approved reconciliation
Tenant reference	Resolve server-side scope	Never trust browser input
Status and timestamp	Track workflow state	Allowlisted values and UTC time
Generic conversion action	Approved aggregate attribution	Off until tenant legal approval
Value and currency	Approved commercial measurement	Use only when approved

Do not copy booking notes, treatment descriptions, contact details, or full customer profiles into the attribution store. Do not use the attribution layer as a CRM or as a browser widget. A narrow store reduces duplication, but it remains subject to access, retention, support, and deletion controls.

Consent, outbound data, and failure handling

Keep outbound sync disabled by default. A tenant-specific approval record should name the purpose, fields, destination, retention, legal reviewer, and expiry or review date. A generic conversion payload may include only an approved click identifier, generic conversion action, value, currency, and opaque deduplication reference. Do not add identity or treatment context.

Use a server-side queue and an outbox. Record the event after the approved internal outcome, then let a worker apply the outbound gate. If approval is missing, the worker must stop and retain a safe internal status. Do not silently retry an event after approval expires.

Handle booking changes explicitly. A cancellation or correction should update internal attribution state, not create a second unapproved event. Use one primary conversion source for each tenant and document deduplication. Browser events and server events should not both claim primary ownership without a defined reconciliation rule.

See one primary conversion source for duplication control. For consent and attribution review, see consent-aware booking attribution.

Integration controls and evidence

Validate webhook signatures, replay protection, event identifiers, timestamps, tenant scope, and status transitions. Store the minimum metadata needed to prove receipt and processing. A failed webhook should enter a controlled retry or dead-letter state, not be reprocessed manually from a copied record.

Audit configuration changes, field allowlist changes, approval changes, support reveals, exports, queue retries, and deletion. Keep event bodies out of logs. Store references to the booking platform rather than mirroring the booking record.

Test the source-of-truth boundary by changing an appointment in the booking platform and checking that the attribution layer follows the approved status. Then try to change the attribution record directly. It should not create a booking or override the source.

Use tenant isolation negative tests for altered tenant values, exports, queues, and support. Use offboarding proof to include the attribution store in deletion.

Tenant approval checklist

1. Confirm the booking platform remains the source of appointment truth.
2. Map the legal and contractual chain for each system and vendor.
3. Approve inbound and outbound field allowlists.
4. Keep advertising sync off until tenant-specific legal approval exists.
5. Verify webhook signature, idempotency, queue, retry, and audit behavior.
6. Run denial, restore, export, and offboarding tests.
7. Record owner, date, evidence, review trigger, and expiry.

Stop when the integration requires a full customer copy, a browser-supplied tenant, a service description sent to an ad platform, or a BAA treated as proof of application compliance. Escalate unresolved questions to counsel.

Frequently asked questions

Why not make the attribution product the booking system of record?

Duplicating booking truth creates conflicting status, access, support, retention, and deletion paths. Keep the platform that already owns booking lifecycle authoritative, and make the attribution layer a narrow, reconciled downstream store.

What may an outbound generic conversion event contain?

Only fields approved for the tenant and destination. A conservative design uses a click identifier, generic action, value, currency, and opaque deduplication reference. It excludes identity, contact, treatment, service, and clinical details.

Does Boulevard coverage approve downstream use?

Not automatically. Verify the current vendor configuration, agreement, API scope, tenant permission, application controls, and legal review. Provider documentation and downstream approval are separate gates.

References

• Boulevard, Boulevard Developer Portal, retrieved 2026-08-15: https://developers.joinblvd.com/
• Boulevard, Protected Health Information Security Requirements, retrieved 2026-08-15: https://support.boulevard.io/en/articles/8550292-protected-health-information-phi-security-requirements
• U.S. Department of Health and Human Services, Minimum Necessary Requirement, retrieved 2026-08-15: https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/minimum-necessary-requirement/index.html