#Projects
The Projects workspace is where partners view and manage project configuration for assigned clients. It uses form-based controls rather than raw runtime YAML.
#Who Can Use It
| Role | Access |
|---|---|
partner_admin | Create projects, view them, edit and save draft configuration, run validation, publish, restore a published version to draft, roll back, archive and restore projects, manage project access, and manage implemented project-workspace domains. |
partner_user | View project workspace state in read-only mode. Draft content is not loaded for this role, and the save, validate, publish, rollback, and restore controls are left out of the page rather than shown as disabled buttons. |
Projects is a partner-only surface. Every other role is denied with a not-found response rather than a permission error, so the portal never confirms whether a project or another tenant exists.
Customer roles use customer-safe Settings pages for approved business controls. They do not edit partner-managed project configuration through Projects.
#Project List
The Projects page is scoped to your confirmed client assignments, resolved on the server. Partner users and partner administrators see only assigned projects. Depending on that scope, the page opens in one of these states:
- Pick a client — when more than one assigned client is in scope, choose a client before any project opens. No editor, validation, publish, or rollback control exists in this state.
- Project inventory — after a client is chosen, a read-only roster of that client's projects with an "Open" action for each. When exactly one project is in scope, it opens directly.
- Project workspace — the sectioned editor for the project you opened.
- Nothing assigned — a calm empty state when no client is assigned to you.
- Project not found — a project link that is stale or outside your scope resolves to a non-enumerating not-found. It never falls back to the inventory and never opens a different project instead.
- List temporarily withheld — when the assignment source is degraded and your selection cannot be confirmed, the portal withholds detail instead of widening what you can see. Retry rather than treating the empty result as the true roster.
Out-of-scope project IDs are denied without revealing whether another tenant or project exists.
#Drafts
A draft is an editable working copy. Saving a draft does not by itself publish runtime changes.
The Projects editor is sectioned by URL fragment so partners can link directly to the area under review. Sections are organised into three groups — Configure, Govern, and Release — and the workspace falls back to #profile when no fragment (or an unrecognised one) is supplied:
Configure:
#profile#project-access#agents#providers#llm-policy#transcript-email#email-sms-policy#sms#transfer-routing#booking#knowledge-plugins
Govern:
#outbound-compliance#identity-verification#governance#recording-transcript
Release:
#release-control#testing-controls#testing-diagnostics#secrets
The #governance section is labelled Compliance in the section rail. Every section listed above appears for a project you can open; what varies by client, project, role, and enabled feature set is the controls and data inside each section, not whether the section is present.
The sticky section header labels the active boundary. Profile saves are profile draft saves only. Runtime validation, publish, drift checks, restore-to-draft, and rollback stay in Release control. Section-specific runtime domains keep their own save or validate controls inside the active section.
Partner administrators can edit implemented project-workspace sections such as:
- project profile fields exposed by the workspace, including project name, timezone, locale, language, and currency
- the welcome greeting, greeting delay, interruption behaviour, and agent instructions in the Profile form
- the weekday Business Hours schedule in the Profile form
- customer-safe form projections
- agent orchestration controls where enabled
- transfer-routing controls where enabled
- telephony, speech-to-text, text-to-speech, and bounded speech-tuning controls where enabled
Project access is managed in #project-access. A partner administrator assigns team members to a project with read or manage visibility, and only assigned members can open it. Assignments cannot be changed on an archived project.
The portal keeps hidden runtime settings, secret-adjacent values, and provider wiring out of the customer-safe browser contract. Configuration forms reject plaintext secrets and raw secret-management paths with a validation error, so do not paste provider credentials, secret names, or provider account details into them.
The Secrets section is the only place a secret value is submitted. You enter the value once, the portal stores a managed reference in its place, and the value is never displayed again — the inventory shows the reference, its category, status, and rotation state only. Rotation replaces the stored value the same way. Partner users can review secret metadata but cannot create or rotate secrets.
#Runtime Domains And Partner Boundaries
The project workspace presents customer-safe controls and summaries for implemented runtime domains. Availability can vary by client, project, role, and enabled feature set; seeing a domain in this guide is not a promise that every tenant has a visible edit form for that domain.
| Runtime domain | Partner boundary |
|---|---|
providers.telephony | Phone-number, provider, DID, and SIP-trunk-adjacent configuration can affect live call routing. Use approved portal/API controls where enabled; escalate production routing uncertainty, carrier account setup, or provider credential changes. |
providers.stt | Speech-to-text provider, model, language, and keyword choices are exposed only as safe selections or summaries where enabled. Provider credentials and account wiring are not partner-facing form fields. |
providers.tts | Text-to-speech provider, voice, sample-rate, and speech synthesis choices are exposed only as safe selections or summaries where enabled. Raw provider credentials remain internal. |
providers.llm | LLM provider, model, realtime/chat mode, and tool-call policy controls are partner-editable only where the project workspace exposes them. Validation can block unsafe or unsupported combinations before publish. |
speech | Speech behavior and tuning controls are separate from STT/TTS provider credentials. Treat them as bounded project behavior controls, not account-level provider setup. |
testing | Testing overrides are for approved development or validation scenarios only. They are not a generic production diagnostics control surface and must not be used to bypass customer-safe publish review. |
email | Email delivery behavior, transcript/report delivery summaries, and template-adjacent settings are surfaced only where enabled. Mail provider credentials, delivery investigation, and template system repairs escalate. |
sms | SMS messaging and consent behavior are surfaced only where enabled. Turning SMS on for a client that does not already have billable SMS enabled opens a billing confirmation showing the per-segment rate; the draft change is only saved after you accept it, and cancelling reverts the provider selection. Phone-number/provider setup, delivery failures, and consent-policy uncertainty escalate. |
identity_verification | Caller verification settings are privacy-sensitive and project-scoped. Partners can manage only exposed policy choices; provider setup and unusual verification failures escalate. |
caller_info | Caller ANI/context injection is a privacy-sensitive runtime behavior. The guide should treat it as a safe summary or bounded setting, not as a way to expose raw caller data. |
rag | RAG is a core project knowledge-base surface. It is not a plugin. Use approved knowledge-base workflows where enabled and avoid uploading secrets or unapproved personal information. |
plugins | Plugins are external service integrations such as booking, CRM, calendar, and workflow systems. Plugin credentials and provider-account setup remain support-owned unless a safe partner control is explicitly enabled. |
webhook | Webhook event delivery is an integration boundary with direct API/reference support where enabled. Webhook secret values are never shown after creation or rotation and must not be pasted into support tickets. |
| Managed secret reference | A managed secret reference is a safe selection boundary for secret-adjacent settings. It is not a place to reveal raw secret values, internal secret names, or host-level secret-management instructions. |
Use Integrations for API keys, webhook/API contracts, catalogs, knowledge-base source workflows, and phone-number integration scope. Use Escalation Boundaries when a runtime-domain change needs production routing work, provider account setup, service log review, or secret handling outside approved portal/API controls.
#Publish
Saving a draft records an editable working copy. It does not publish live runtime changes.
Validation checks the current draft or publish candidate against project-workspace rules. Results are grouped as blocking, review, passed, and pending. Blocking findings must be resolved before publish.
Publish has two preconditions and the portal refuses the action without them: there must be a saved draft to publish ("Save a draft before publishing.") and a validation report produced for it ("Run validation before publishing."). Validation is a required step, not an optional pre-check.
Publishing creates an immutable published version from the current draft and starts or records the deploy-status flow used by the current API. The recorded outcome distinguishes a deploy that is pending, completed, or failed, so a successful publish is not by itself proof that the runtime deploy finished. Publish validation can block changes when required fields, runtime-domain rules, or project-workspace constraints are invalid.
Publish and rollback are submitted with an idempotency key derived from the release you are acting on, so an accidental repeat submit of the same release does not create a second version.
For agent, transfer-routing, provider configuration, RAG, webhook, plugin, messaging, testing, and secret-adjacent changes, partner-safe validation messages should not include raw prompt text, bearer tokens, internal secret-management references, provider secrets, full phone numbers, transcripts, raw customer PII, or other secret material.
Current publish behaviour records version and deploy-status metadata, and project mutation audit trails should be used with the version record when reviewing who changed configuration and when. Do not assume the portal publish action directly rewrites mounted runtime YAML unless AiDial has confirmed that runtime path for the environment.
#Version History And Rollback
Published versions are listed in version history with their version number, validation status, deploy status, and whether they are eligible for rollback. Restoring a published version replaces the current editable draft with that version's configuration; it does not silently change live runtime configuration. Review the restored draft, save any required changes, and publish again when ready.
Use "restore to draft" language when explaining rollback. It keeps the save/publish boundary clear, preserves reviewable version history, and avoids implying an unaudited live change.
Runtime rollback is offered only for a version marked rollback-eligible, and the target version is validated before the rollback is submitted. A target that does not pass validation is refused with its findings rather than rolled back.
"Check drift" and "Compare latest to draft" are read operations and stay available to read-only viewers. Version comparison redacts secret-adjacent values in the diff, so a compare view will not reveal stored secrets.
Restore to draft, runtime rollback, and disabling testing controls require an explicit confirmation step in the portal before the action is submitted.
#Testing Controls And Diagnostics
Testing controls hold test-only overrides. They stay separate from the published production runtime, and published versions carry a summary showing whether a test state is active while confirming that the published runtime is unchanged. Disabling testing controls clears the test-only override contract and requires confirmation.
Testing and diagnostics is an operations-mediated request surface, not a call-placing control. A partner administrator submits a short free-text note (up to 2000 characters) describing what is needed for a guided test call, and the portal records the request against the project — it does not dial. Diagnostics return pass/fail summaries only. Do not put transcripts, recordings, caller details, or credentials in the request note.
#Archive And Restore
Partner project lifecycle endpoints support archiving and restoring projects where your role and assignment allow it. Archiving and restoring are partner-administrator actions. An archived project switches the whole workspace to read-only — it cannot be edited or published, and its project access cannot be changed, until it is restored.
If a project needs deletion, emergency reversal, runtime repair, or data recovery, use Escalation Boundaries.
#Safety Boundaries
Do not put these details into project forms, support requests, or public documentation:
- API keys or bearer tokens
- Secret-management paths or secret names
- internal host names or SSH steps
- raw provider credentials
- production customer PII
- database maintenance or data-repair instructions
- deployment template details
#Related Pages
- Project configuration lifecycle: contact your AiDial partner contact for lifecycle details not covered on this page.
- Roles & Permissions
- Clients
- Integrations
- Escalation Boundaries