Manage workspaces

A workspace connects one project environment to Terraform source, provider context, revisions, governance controls, and runs.

Typical time

5–15 minutes

You need

Project and workspace access

Outcome

A reviewed workspace or queued check

Choose scope and find a workspace

1. Open Workspaces.
2. Select an exact project to enable create and mutation actions.
3. Choose the all-projects view only for read-only cross-project review.
4. Enter a name in Search workspaces….
5. Narrow results with Environment, Provider, and Status.
6. Choose Clear filters to remove the filters.
7. Use the page-size selector and Previous or Next.
8. Choose Refresh workspaces to request current data.

Exact-project pages use backend cursor pagination. The all-projects view aggregates permitted project results for read-only browsing; mutation controls stay unavailable until you select one project.

Workspaces 1 of 6 · Screenshot placeholder

Scope and filter the workspace list

Show project scope, Search workspaces, Environment, Provider, Status, Clear filters, Refresh workspaces, and pagination.

Future capture briefUse synthetic projects and workspaces. Hide IDs, account labels, repository URLs, run IDs, costs, and tenant details.

Check your result

The scope banner and each visible workspace row belong to the project context you intended.

Create and open a workspace

1. Select an exact project.
2. Choose Create Workspace.
3. Complete and review the guided workspace form.
4. After creation, choose Open on the workspace row.
5. ScrinCloud opens its saved destination, such as Architecture Studio or the Terraform code editor.

Creation is a backend mutation that saves workspace state and a revision. It does not run Terraform or deploy infrastructure. Follow Set up a workspace for every creation field.

Review workspace details

1. Open the row action menu and choose View details.
2. Review Workspace Summary, Terraform Setup, Latest Run, Governance & Controls, and Metadata.
3. Choose View Runs to inspect run history.
4. Choose Open Project to return to the parent project.
5. If no provider account is selected, Go to Cloud Accounts opens the connection surface; it does not create a connection automatically.

These are read or navigation actions. The detail drawer intentionally does not offer a state download. State summary and download requests belong to the governed Terraform settings workflow.

Workspaces 2 of 6 · Screenshot placeholder

Review workspace configuration and activity

Show Workspace Details with View Runs, Queue Plan, Edit, Open Project, Delete, and the main summary sections.

Future capture briefUse synthetic values. Redact workspace and revision IDs, account connections, repositories, branch names, run IDs, variables, and tags.

Check your result

The workspace, project, provider, environment, region, and latest revision are consistent with the row you selected.

Edit a workspace

1. Choose Edit.
2. Wait for ScrinCloud to acquire the edit lock and load the latest revision.
3. Review Workspace details, Terraform config, Runtime & governance, and Review changes.
4. Update only the intended fields.
5. Use Add Variable and remove-variable controls only for non-secret values.
6. Add or remove tags as needed.
7. Review Auto Plan, Apply Approval, Approval Gate, and Custom Terraform with your project policy.
8. Choose Save Workspace and wait for the new immutable revision.

Editing is a backend mutation. Never place credentials, tokens, private keys, passwords, or connection strings in workspace variables.

Workspaces 3 of 6 · Screenshot placeholder

Review Terraform and governance changes

Show the four edit steps, variables and tags, governance controls, Review changes, and Save Workspace.

Future capture briefUse non-secret synthetic variables. Hide repository URLs, branch names, provider accounts, revision IDs, and tenant identifiers.

Check your result

Reopen View details and confirm the new values and latest revision. The edit lock should no longer block another authorized editor.

Run a validation

1. Select an exact project and locate the workspace.
2. Choose the row’s Validate button or Run validate in its action menu.
3. Wait for Validating… to return to its normal label.
4. Choose View runs to inspect the queued validation and its terminal result.

Validation creates a governed run request against the saved revision. It checks the configuration; it does not apply Terraform or change cloud resources.

Queue a plan

1. Confirm the workspace has a latest revision and you have write permission.
2. Choose Queue plan from the row menu or Queue Plan in details.
3. Wait for Queuing… to complete.
4. Choose View runs and inspect the plan run, logs, policy results, and plan artifact before any later approval.

Queueing a plan is a backend side effect and uses an idempotent request. A plan is a proposal, not proof of an apply or deployment.

Workspaces 4 of 6 · Screenshot placeholder

Validate or queue a plan for one revision

Show the Validate control, Run validate and Queue plan menu actions, latest revision readiness, and View runs.

Future capture briefUse a disposable non-production workspace. Hide run, revision, account, repository, and cloud-resource identifiers.

Check your result

Run history shows one request for the intended workspace revision. Use its terminal status—not the button notification—as the result.

Delete a workspace

1. Choose Delete workspace from the row menu or Delete in details.
2. Read Delete workspace? and confirm the project and workspace.
3. Verify retention, state, run-history, and external-resource cleanup policy.
4. Choose Delete workspace and wait for completion.

Deletion is destructive and requires write access. Removing application workspace metadata does not prove that external cloud resources or Terraform state were destroyed.

Workspaces 5 of 6 · Screenshot placeholder

Confirm workspace deletion safely

Show Delete workspace? with the selected synthetic workspace, impact text, cancel action, and Delete workspace confirmation.

Future capture briefUse a disposable non-production workspace. Hide state details, account IDs, repository data, run IDs, and tenant identifiers.

Check your result

The action completes and the workspace no longer appears after Refresh workspaces.

Understand the proof boundary

Workspaces 6 of 6 · Screenshot placeholder

Confirm the workspace action in the correct evidence surface

Show the refreshed workspace list beside a terminal run status or updated latest revision, without claiming an external deployment.

Future capture briefUse synthetic non-production evidence and redact state, plan, log, repository, account, and cloud identifiers.

Workspace pages can prove saved metadata, revision creation, and that a run was queued. Only the run’s terminal evidence can prove validation or plan outcome. Only an authorized apply and provider-side verification can prove a cloud change.

Common blockers

Create or run actions are disabled

Select an exact project, confirm write access, and ensure the workspace has a latest revision.

Edit lock is unavailable

Another editor may hold the lock. Do not bypass it. Wait, coordinate with the editor, or retry after the lock is safely released.

Provider account is missing

Use Go to Cloud Accounts and follow the connection guide. Visual review may work without a connection; provider-backed runs may not.

Validation or plan is queued but has no result

Open View runs and wait for a terminal state. A queue acknowledgement is not a successful validation or plan.

State download is not in Workspace Details

That is intentional. Use the governed Terraform settings and audit workflow; do not look for or document a hidden workspace shortcut.