Launch an application with your team

Status: Upcoming — not yet available.

Section: DOC-CP-workspaces-projects#overview.

Set up a Travila project for your application, make the first permitted call, and give teammates access without sharing one person's credentials. This recipe takes a new team from signup through a tested configuration to live use.

Available today: use the account and credentials supplied by your administrator and follow the HTTP quickstart. The current public API uses the legacy default project. Self-service first-project creation, multiple projects and separate test/live modes are not yet available; a different project header or a key named “test” does not enable them.

The following workflow describes the upcoming project experience. Your first project is part of onboarding, so setup finishes with a usable place to build your application.

Choose the home for your application

Status: Upcoming — not yet available.

Section: DOC-CP-workspaces-projects#workspace-model.

Use a workspace for your company and a project for each application. For example, a team building a support assistant creates one project for that application; it adds a second project when it builds a separate sales assistant.

Choose a supported data region before creating the project. That region is fixed for the project, so check your data placement requirements before continuing. Each project provides test and live modes for preparing changes and serving customers.

If your application serves several business customers, use a project customer identity for each one. The identity is shared across test and live, while records, users and connections remain separate in each mode. Records with no customer assigned form their own unassigned selection; that selection does not mean “all customers.”

If you manage a separate business's own Travila workspace, it remains an independent workspace and grants you the access you need. Follow Travila for Platforms for that relationship. Ownership, permission to operate and responsibility for payment are separate choices.

Create the first project and make a test call

Status: Upcoming — not yet available.

Section: DOC-CP-workspaces-projects#first-project-setup.

1. Create or join your workspace. Verify your identity through signup or accept a verified invitation. A company's name or email domain alone does not grant membership in its workspace.
2. Create the application project. Give it a name and choose a supported, permitted data region. Review the capabilities and capacity offered there.
3. Wait for the required capabilities to be ready. Setup shows its progress and names any quota, capacity or integration step that needs attention. Use the recovery steps below if setup is interrupted.
4. Review the included allowance. See the finite free usage and remaining capacity before making the first call. You can use the applicable allowance without entering payment details; permission to incur paid spending is separate.
5. Create a service credential for test. Select its owning service, project, mode, permissions and expiry. Store the returned secret securely on your backend. Reloading the page does not reveal the old secret or create a replacement key.
6. Make the first permitted call. Follow the conversation quickstart with the selected project's supported credentials and verify the returned result. Authorization and finite usage limits apply from this first call.

You have completed onboarding when the first project and required capability are ready and your application can make its first authorized call. Keep the project and operation references if a setup step needs recovery.

Resume setup after an interruption

Status: Upcoming — not yet available.

Section: DOC-CP-workspaces-projects#project-readiness.

Reopen the original project operation if the browser closes or a request times out. Recovering that operation returns the same project and its progress, so a slow setup does not create duplicate projects.

Setup shows	Next step
Pending	Continue from the original operation and inspect the remaining step.
Requires action	Complete the named prerequisite, such as capacity approval or a required connection.
Ready	Check that the particular capability your application needs is ready, then make the test call.
Failed or uncertain	Keep the project and operation references and ask the responsible account contact to reconcile or retry the failed step.

When requesting help, include the intended application, region, required capability, operation reference, last observed state and time. Leave credentials out. A project can exist while one capability still needs setup; readiness makes that unfinished work visible.

Invite teammates without sharing service keys

Status: Upcoming — not yet available.

Section: DOC-CP-workspaces-projects#people-and-service-ownership.

Assign each ordinary workspace member to the projects they need. Workspace administrators inherit project access. Your teammates can then manage their assigned work without passing a personal credential around the team.

Keep application keys owned by the project and service that use them, with a current responsible contact and the creator recorded in audit history. When a developer leaves, remove their workspace membership to end all their project access. The independently owned service key continues to work; review possible secret exposure separately and rotate or revoke exposed keys.

When demoting an administrator who remains a workspace member, review direct project assignments too: separately granted access can remain. Test and live service credentials stay pinned to their permitted project and mode, so a test credential cannot run live work.

Try a configuration change before serving customers

Status: Upcoming — not yet available.

Section: DOC-CP-workspaces-projects#test-and-promotion.

Configure the support assistant in test and run representative conversations with controlled data. Test starts without live provider credentials or destinations. If you deliberately connect a real external account, its tools can still send messages, change data or incur charges.

Once the change gives the intended result, select the tested configuration version and the live destination. Review the difference and promote it using source-read and destination-write permission. Promotion copies the selected agent configuration; credentials, conversations, schedules and customer history stay in their original mode.

Verify the live assistant's result after promotion. An authorized teammate can also edit live directly, and the configuration history identifies that edit separately. Until project modes are available, use the current integration testing workflow with its stated isolation limits.

Bring an existing integration into the project model

Status: Upcoming — not yet available.

Section: DOC-CP-workspaces-projects#existing-account.

Keep using your administrator-provisioned account until its migration is supported. Record the application credentials, required scopes, user-identity setup, connected accounts, usage allowance and spending permissions that the existing integration depends on.

During an agreed migration, preserve verified project and resource identities and resolve unmapped ownership before moving traffic. Afterward, repeat the application's main flow with the intended project credentials and verify the user and usage attribution. Naming a legacy credential after the new project is not a migration or an access boundary.

Use authentication and integration testing for the currently supported path. Current test fixtures can invoke real models, tools and recipients; arrange controlled destinations with your administrator.

Retire or relocate an application deliberately

Status: Upcoming — not yet available.

Section: DOC-CP-workspaces-projects#project-lifecycle.

When you need to stop the assistant immediately, suspend its project to stop new work. Track requests already sent to external services separately; suspension does not undo those actions.

Choose the next step according to what your team needs to keep:

Your goal	Action and result
Pause an application while preserving eligible data	Archive the project and check the disclosed restoration deadline and exclusions. An eligible restore does not revive revoked credentials.
Clear test fixtures and continue serving customers	Reset only the authorized test scope; live data stays available.
Remove one application's customer	Suspend or erase that customer across both modes and follow cleanup for each capability.
Close the workspace	Track cleanup, pending provider actions and records retained under an approved exception until the requested scope is accounted for.
Move to another data region	Create a project in the new region and approve a migration covering identities, moved data and any retained copies. Changing a workspace preference does not move existing data.

Changing the payer or accepting an Enterprise agreement preserves workspace, project and credential identities unless a separate migration is agreed. Earlier usage keeps its original attribution, and payment does not remove an independent security restriction. See billing and spend.

Document ID: DOC-CP-workspaces-projects. Section identities and revisions.