Reference Deployment

Review the logical boundaries, data flows, integration dependencies, and ownership decisions in a Concurrence deployment before selecting a pilot architecture.

This reference follows an application-hosted scheduling workflow using a managed Concurrence workspace and a customer scheduling system. It shows the logical responsibilities that must be connected. Confirm the actual regional services, hosting arrangement, external processors, and network paths for your deployment using Data Residency.

Follow the Data and Decisions

Flow	What crosses the boundary	What to verify
1. Application access	An authenticated user's request reaches the customer's trusted backend and the supported Concurrence access path	Credential scope, user-to-entity resolution where needed, and which service the user may invoke
2. Source context	Supported source records enter the workspace and become usable context after the applicable processing	Source ownership, mapping, freshness, identity linkage, and evidence that the needed record is queryable
3. Workflow execution	The selected service resolves agent/graph configuration, available context, and eligible actions	Which configuration was selected, what is prompt guidance, and what authorization or validation actually enforces
4. External action	A configured integration sends an authorized request to the scheduling system	Target credentials, approval policy where enabled, error behavior, acknowledgement, and independent read-back
5. Evidence and operation	Conversation/run records and supported analytical or audit views inform application and operator decisions	Access, retention, missing evidence, exception routing, and who reconciles ambiguous results

The diagram does not place every external provider inside Concurrence's regional boundary. A phone, SMS, email, or other managed channel adds provider processing and delivery controls; use the channel availability matrix. Scribe uses its own provider/session contract and is not the same integration as application text.

Decide the Integration Boundary

For an application you own, keep long-lived workspace credentials in the trusted backend. Use the supported scoped access flow for browser sessions. See Serve an Agent From a Web App.

For source data, specify the minimum records and relationships needed by the workflow. Import or connector acceptance is not proof that the serving view or caller binding is ready. Verify the actual read path before asking an agent to act on it.

For external writes, choose the actual integration endpoint and permitted principal. Where approval is enabled, identify the reviewer and the behavior while a decision is pending. The direct-integration approval flow and connector write-back review are separate capabilities. Target acknowledgement remains a separate requirement after either decision.

Assign Responsibility Before Estimating Effort

Work item	Customer responsibility	Concurrence / implementation responsibility	Evidence that closes the dependency
Workflow and outcome	Define eligibility, intended result, exceptions, and baseline	Map the workflow to supported configuration and controls	Agreed workflow and failure cases
Identity and access	Own user identities, roles, consent evidence, and source access decisions	Configure supported access and service linkage	Positive and negative access tests
Source integration	Supply test records, source contract, access, and mapping decisions	Configure the agreed ingestion/read path	Queryable synthetic case with attributable source
External action	Provide target contract, scoped credentials, test environment, and reconciliation owner	Configure and validate the agreed action path	Target acknowledgement and read-back, plus a failure case
Channel readiness	Approve intended communications and staff exceptions	Provision supported managed resources and routing as agreed	Test on the intended channel with delivery evidence
Evaluation and release	Approve acceptance criteria and operating policy	Supply configuration evidence and execute agreed validation	Reviewed case results and release decision
Ongoing operation	Own business exceptions and downstream corrections	Own platform operation and agreed implementation support	Escalation route, access, and recovery exercise

These are planning responsibilities, not a substitute for the agreed support or commercial terms. Record named owners and any different allocation in the evaluation packet.

Estimate Dependencies, Not a Universal Timeline

For each work item, record access lead time, unresolved design decisions, implementation effort, validation effort, owner, and blocking predecessor. Source-system access, identity mapping, managed sender readiness, and customer review can dominate the calendar even when the client code is small.

Separate the initial technical connection from a deployable workflow. A successful first conversation verifies a narrow integration milestone; it does not complete channel readiness, target reconciliation, or operational acceptance.

Review Portability and Recovery

List the configuration, records, traces, and analytical data you need to retrieve, then identify the supported export or access path and permission for each. Confirm format, scope, freshness, retention, and contractual constraints. Retrieve a representative sample and verify that the receiving system can interpret it, including identifiers and provenance. Record any transformation or reconstruction work required.

Test restoring a reviewed configuration and separately test how the team handles external actions that already occurred. Reverting an agent configuration does not reverse an appointment change, message, or other target-system mutation.