#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`	View projects, edit draft configuration, save drafts, publish drafts, restore a published version to draft, and manage implemented project-workspace domains.
`partner_user`	View project workspace state in read-only mode.

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 loads projects in scope for your signed-in account. Partner users and partner administrators see only assigned projects. 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 partner users can link directly to the area under review:

#profile
#project-access
#agents
#providers
#llm-policy
#transcript-email
#outbound-compliance
#sms
#transfer-routing
#release-control
#testing-controls

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
business-hours summary fields used in the partner workspace
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

The portal keeps hidden runtime settings, secret-adjacent values, and provider wiring out of the customer-safe browser contract. Provider credentials are selected by safe project_vault references only; do not paste raw provider secrets, internal secret-management paths, or provider account details into project forms.

#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. 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.
`project_vault`	`project_vault` is a safe reference and 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. Blocking findings must be resolved before publish.

Publishing creates an immutable published version from the current draft and starts or records the deploy-status flow used by the current API. Publish validation can block changes when required fields, runtime-domain rules, or project-workspace constraints are invalid.

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. Restoring a published version creates a new draft from that version; 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.

Restore to draft, runtime rollback, and disabling testing controls require an explicit confirmation step in the portal before the action is submitted.

#Archive And Restore

Partner project lifecycle endpoints support archiving and restoring projects where your role and assignment allow it. Archived projects cannot be edited or published until 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

Project configuration lifecycle: contact your AiDial partner contact for lifecycle details not covered on this page.
Roles & Permissions
Clients
Integrations
Escalation Boundaries