> For the complete documentation index, see [llms.txt](https://docs.concurrence.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.concurrence.com/platform-overview/reference-deployment.md).
# 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](/platform-overview/data-residency.md).
## 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](/platform-overview/capability-availability.md). 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](https://docs.concurrence.com/developer-guide/platform-api/conversations/serve-agent-from-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](/platform-overview/evaluation-packet.md).
## 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](https://docs.concurrence.com/developer-guide/guides/first-verified-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.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.concurrence.com/platform-overview/reference-deployment.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
