Workspace settings¶

A Workspace is the tenant boundary for an application. Its Resource data, Files, Pages, Workflows, domains, brand settings, and users are isolated from other Workspaces.

System Administrators manage workspace settings from the workspace's System Admin area. Diagonal platform operators use the separate Control Panel for cross-workspace administration.

Domains¶

Every Workspace is available on its Diagonal workspace host and can have custom domains. The Domains settings page shows DNS status and lets you choose the primary custom domain.

When automatic domain setup is enabled:

Add one hostname, such as portal.example.org.
Add the DNS records shown on its detail page.
Leave the records in place. Diagonal checks them for up to 30 days and sets up HTTPS when they resolve.

Workspace System Administrators receive an email when automatic setup first makes a domain live. They receive another email if Diagonal stops checking after 30 days. These emails require automatic setup and outbound email to be enabled. Pausing and resuming a live domain does not send another live email. Open the domain page to see progress and DNS instructions.

Diagonal checks each live domain once an hour. If its DNS records or HTTPS setup stop matching, the domain page shows a Needs attention warning and the list shows a warning beside Live. Diagonal confirms a problem with a second check a few minutes later, so a short DNS interruption does not raise a warning. Workspace System Administrators receive one email when the problem is confirmed. The domain stays Live; Diagonal does not turn it off. Fix the records shown on the domain page, then select Check now. The warning clears when every check passes. If a domain that was verified before its move depends on an _acme-challenge verification record and that record is missing, the warning says that the HTTPS certificate cannot renew until you restore it.

The first live domain becomes your primary address. Pages, canonical links, and the sitemap use the primary address. The list shows the domains that need your action first. You can use Check now to check progress. Imported domains start Waiting for DNS with automatic checks stopped. Select Check now to start them in the destination Workspace.

A subdomain needs one CNAME record pointing to domains.go-diagonal.com. A root domain needs the displayed A record values and a CNAME from www to domains.go-diagonal.com. Both must resolve before setup starts. If the root domain already serves a website, use a subdomain or wait for the website-move flow before changing DNS.

The detail page shows who must act next, the next step, and the setup stage. It lists each record with the name to enter, its value, its purpose, and its status. The status is Found, Not found, Wrong value, or Conflicting. A problem includes a specific fix. The purpose tells you whether to keep the record permanently or remove it after the domain is live. When Diagonal detects your DNS provider, the Name column shows the name that provider expects. For example, a provider that adds example.org needs portal in the Name field, rather than portal.example.org. Use the copy buttons to copy the exact name and value.

You can keep a Cloudflare traffic proxy enabled. Add each permanent _acme-challenge CNAME shown on the page and set it to DNS only in Cloudflare. A root domain also needs the companion verification record for www. Keep these records in place. Public DNS cannot confirm a proxied traffic origin. Diagonal waits for the hosting service to verify it; HTTPS setup with a proxy can take about 20 minutes.

The Certificate authorization section checks CAA policy separately. You do not need a CAA record when no policy restricts issuance. If an applicable policy blocks Google Trust Services, the fix identifies the record owner that must allow pki.goog.

Status	What happens next
Waiting for DNS	Add the records. Diagonal checks automatically.
Verifying	Diagonal sets up HTTPS. This usually takes under 15 minutes.
Live	Keep the DNS records in place.
Needs attention	Follow the specific fix. Diagonal retries setup after repair.
Paused	Contact support to turn the domain back on.
Stopped checking	After 30 days, add the records and select Check again.

A failed HTTPS setup restarts automatically after DNS checks pass. Diagonal permits five restart attempts in any 24-hour period. If the limit is reached, the detail page shows when another restart is available. Check now still checks DNS and does not reset the limit. Automatic attention checks stop after 30 days. Fix the problem and select Check again to restart them. Imported domains remain idle until you select Check now.

For a page-route conflict, a domain held by another hosting environment, or a hosting configuration problem, follow the support guidance on the detail page. Diagonal keeps healthy hosting domains when retrying route activation or a temporary hosting failure.

If someone else manages DNS for the domain, such as a web company or an IT contact, select Share instructions on the domain detail page. Select Create link to make a read-only link. The recipient does not need a Diagonal account.

Use Copy link or Copy message to send the link through email or chat. The message contains the hostname, the link, its expiry date, and guidance about the website and email records.
The link works for 30 days. Copying it again does not extend it. After it expires, select Create link to make a new one.
Anyone with the link can view the instructions. Select Revoke link to stop it immediately.
The page shows the required records, the latest saved check results, and the time of the last check. It does not run a new check. While automatic checks run, the open page refreshes every 30 seconds.
For a subdomain, the instructions connect only that subdomain. For a root domain, changing the A and www records moves the website. Both tell the recipient to keep the existing email records and not to change nameservers or MX records.
A link stops working when you revoke it, when it expires, when the domain or Workspace is deleted, or when the hostname changes. Restoring a deleted domain does not restore its link. Links are not included in exports, imports, packages, or branches.

After you delete a domain, remove its DNS records at your DNS provider. Records that still point to Diagonal can let another Workspace connect the same hostname.

When automatic setup is disabled, the add dialog retains the staff setup instructions. Administrators can check DNS and set the domain live manually.

A Workspace can have several active domains but one designated primary custom domain. Pages, canonical links, and sitemap URLs use the primary domain, unless a Page is assigned to a specific active domain, in which case it serves on that domain instead. If the primary domain becomes inactive or is deleted, Diagonal updates the designation through the domain lifecycle; don't rely on an inactive domain as a fallback.

Brand Kit¶

The Brand Kit controls shared presentation used by workspace Pages and supported embedded experiences:

logos, favicon, and social sharing image;
light and dark color tokens;
typography and web fonts;
radius and shadow tokens;
design profile and theme preset;
SEO title and description defaults.

Save Brand Kit changes from the settings page. Pages that define their own values can override shared presentation, while Pages that use Brand Kit tokens receive the updated values.

Public brand assets should use Files intended for public delivery. Don't place private customer documents in logo, favicon, or social-image settings.

Email settings¶

Outbound emails enabled is a workspace-level switch. Turning it off prevents the workspace from sending outbound email even when email Workflows and provider configuration exist. Turning it on doesn't configure a sender or fix an invalid email integration by itself.

Use the switch when preparing or suspending a workspace without deleting its email Workflows.

Workspace values¶

Workspace Fields store shared application values such as name, default currency, sidebar presentation, homepage, email behavior, and custom configuration. Workflows, Pages, and Resolvers can read these values without hardcoding them.

Treat system Workspace Fields as platform settings. Custom fields are suitable for builder-owned configuration, but don't rename or repurpose a system key used by the runtime.

Child Workspaces¶

Some Workspaces are marked by Diagonal staff as parent Workspaces. Their System Administrators can create and manage white-labeled child Workspaces.

Creating a child Workspace requires an initial administrator's name, email, and password. The new Workspace includes a team Resource named for the parent, one administrator Record, and a blank homepage. The initial Record receives the System Administrator role.

The child detail page lists its enabled Authenticatable Resources. Select a Resource to search, sort, and browse its Records. Log in opens the child workspace’s /admin page in a new tab as the selected Record. The parent tab stays signed in. This is a direct login, with no impersonation banner or exit action.

The child detail page is read-only. Manage Records and roles inside the child Workspace. No Resource has a special workspace-level team designation.

Only a Diagonal platform administrator or a System Administrator of the enabled parent Workspace can manage its children. Other Workspaces don't see these routes.

Branches¶

A branch is a copy of your Workspace that you can build in without touching the live one. Only a System Administrator sees these screens, at Settings → Branches.

New branch copies the whole Workspace — Pages, Workflows, Resources, every Record, and every file — into a new Workspace of its own. You watch the copy run from the Branches list, and the branch opens once it is done. It copies the whole team as it is, so every copied account signs in to the branch the way it signs in here. The branch page also lists the copied accounts, and opens the branch as any of them.

Open takes you into the branch. Build there exactly as you build in the Workspace it came from.

Update from main brings in what changed in the Workspace since the branch was copied, or since its last update. Your changes in the branch stay. Where the Workspace and the branch changed the same thing, or one side removed what the other side changed, you choose which version to keep. Apply update changes only the branch; the Workspace stays as it is. The branch stays open, and the page shows what the last update brought in. Mark the branch ready again after an update, because the next merge compares against the updated branch. Records are not updated.

Ready to merge works out what the branch changed. Use it again after more work; the newest one is the one that merges.

Review changes lists every difference between the branch and the Workspace it came from, grouped by kind of content. Each row has a box you tick to apply it or clear to leave the Workspace as it is. Where both sides changed the same thing, you are asked which version wins.

Merge branch applies exactly what you ticked. The Workspace keeps the result as its own content, and the branch Workspace is removed. The branch stays in History with what it changed and the answer you gave for each item.

A merge carries what you built: Pages, Workflows, Resources and their Fields, Components, Navigation, Email Layouts, and Workspace settings. It never carries Records. The Records in a branch are a copy of the Workspace's data for trying your work against, plus whatever test data you make; they stay in the branch and go with it.

Discard ends a branch without merging. Its Workspace and everything in it are removed. The Workspace it came from is not changed.

A branch never sends email and never runs a schedule. Scheduled Workflows, Record schedules, and subscription billing are all off in a branch, so a working copy can never mail a real customer or bill one. Custom domains stay with the Workspace they belong to; a branch is reached through its own Diagonal address.

Semantic search returns nothing inside a branch, because Record embeddings are not generated there. A branch mails no Magic Link and no password reset, whatever its email settings say, so a copied account signs in to a branch with its password.

Diagonal keeps the working copies of a branch — the snapshots it compares — only while the branch is open. They are removed once the branch is merged or discarded. The History entry, with what changed and the answer you gave for each item, stays.

Import, export, and deletion¶

Platform operators can export a Workspace and import its definitions and Records through the Control Panel. Imports restore definitions before Records, then reconcile system Roles, Permissions, and indexes.

Permanent deletion coordinates PostgreSQL data, Mongo Resource data, Files, caches, and dependent module cleanup. It isn't an archive and can't be undone from the workspace UI.

Permanent deletion

Export anything that must be retained before a platform operator deletes a Workspace. Removing a Workspace row or domain is not a safe substitute for the coordinated deletion operation.

Control Panel versus System Admin¶

Surface	Who uses it	Scope
Workspace System Admin	A permitted Resource identity	One Workspace's Resources, Pages, Workflows, settings, domains, and Media Library.
Diagonal Control Panel	A platform User with operator access	Workspaces and platform Users, package library operations, impersonation, execution/email/conversation inspection, tokens, and AI evaluations.

The two surfaces use separate accounts and logins. A Workspace System Administrator isn't automatically a Control Panel user.

Verify a previously connected address¶

A new subdomain normally needs only its CNAME record. If an address was released by another workspace, Diagonal also shows a TXT record. An address with unknown former ownership uses the same verification step.

This address was connected to a different workspace. Add this TXT record to verify that you control it.

Copy the exact TXT name and value from the DNS records table. The name starts with _diagonal-challenge.. The value starts with diagonal-verification=. Keep the full value and its letter case. Diagonal does not show the previous workspace's identity.

An apex address uses one TXT record for the apex and its managed www alias. It also needs the displayed A and www CNAME records. Other subdomains have separate setup records.

Diagonal checks the TXT before connecting hosting and again before the address goes live. A saved successful check cannot replace these checks. Keep the TXT until activation finishes. After activation, leave the routing DNS records in place and remove the TXT record if you want. Proof is required until the first activation. After that, the address no longer lists the TXT record in any status. If it returns to Waiting for DNS or support pauses it, it can go live again without the TXT record.

Retries keep the same verification value. Deleting an unverified request and adding the address again produces a new value. Older values do not verify the new request. You can reclaim an address your own workspace released without TXT verification, including an address you removed before it went live. Importing a workspace resets domain verification and hosting state; imported addresses wait until you select Check now.

Support can activate a challenged address while impersonating your workspace. Diagonal records that override and the original staff identity in its internal audit history. Released address history remains after permanent workspace deletion so another workspace cannot take over through routing DNS left behind.