KDesk Client Secrets

This article explains how Client Secrets work in KDesk, including templates, secret records, access controls, reveal protection, ticket linking, and member permissions.

What Client Secrets Are

Client Secrets are secure operational records used to store sensitive client-facing or environment-specific information inside a workspace. They support structured fields, masked sensitive values, restricted access, and ticket linkage so teams can keep high-risk data out of normal ticket comments and payloads.

The Two Main Parts

Record type	What it does
Client Secret template	Defines the field layout for a type of secret, including labels, field types, required flags, sensitive flags, and choice options.
Client Secret	Stores the actual secret record, including template, name, description, active state, expiration date, assignments, dynamic rules, related tickets, related contacts, and field values.

Templates define the structure. Client Secret records hold the actual data and access policy.

Templates

Templates let a team standardize how secrets are stored. A template can include fields such as API keys, tenant identifiers, instructions, attachments, and recovery notes. Supported field types currently include Text, Choice, Message, and File.

Each field can be marked as required, and non-file fields can also be marked as sensitive. Sensitive fields stay masked by default and require an explicit reveal action later. File fields are stored on the Client Secret itself and are intentionally kept out of normal ticket payloads.

Client Secret Records

A Client Secret record starts from a template and adds the real operational data. Staff can set the name, description, active state, expiration date, related tickets, related contacts, static assignments, and dynamic access rules.

Client Secrets can also be linked to tickets so members working a ticket can find the relevant secure record from the ticket itself without copying the secret into comments or messages.

Access Models

KDesk supports two access patterns for Client Secrets:

• Static access: assign specific team members directly to the Client Secret.
• Dynamic access: grant access through rules tied to membership attributes or ticket context.

A Client Secret can also carry related tickets and related contacts, which are used by some of the dynamic rules.

Dynamic Access Rules

Rule	What it does
Member title matches	Grants access when a member title matches a configured pattern.
Member division matches	Grants access when a member division matches a configured pattern.
Can access linked tickets	Grants access when the member can access any ticket listed in the secret’s related tickets.
Can access current ticket	Grants access when the member can access the ticket where the secret is being viewed.
Current ticket matches related contacts	Grants access when the current ticket includes one of the contacts linked to the secret.

Any matching dynamic rule can grant access. This makes Client Secrets useful for ticket-driven operations where the correct users change from one ticket to another.

Sensitive Fields and Reveal Actions

Sensitive fields are never shown in plain text by default. Members must explicitly click Reveal to view them. If the workspace requires extra protection, KDesk can force an email verification step before reveal actions are allowed.

When reveal verification is enabled, KDesk sends a verification code to the member’s email address. The member enters that code to unlock reveal actions, and then they can reveal the requested sensitive field. This creates a tighter control point around high-risk data exposure.

Expiration and Recovery

Client Secrets can have an expiration date. Expiration helps teams identify credentials or operational values that should be rotated. Expired secrets can still remain in the system for tracking, but revealing an expired secret may be restricted to higher-permission users and may prompt for extra confirmation.

Ticket-Level Usage

On a ticket, the Client Secrets panel shows the secrets relevant to that ticket when the feature is enabled and the member has access. Members can view fields, reveal sensitive values, download attached files, and link accessible secrets to the ticket when their permissions allow it.

This keeps operational context attached to the work item without forcing teams to expose secrets in comments, emails, or general ticket metadata.

Permissions

Permission	What it allows
View assigned Client Secrets	View Client Secrets the member can access through assignment or matching rules.
Modify assigned Client Secrets	Edit Client Secrets the member can access.
View all Client Secrets	View all Client Secrets in the workspace regardless of assignment.
Modify all Client Secrets	Create, edit, and manage all Client Secrets and Client Secret templates.
Account owner	Full Client Secret access.

The main Client Secrets page only appears when the workspace has Client Secrets enabled and the signed-in member has one of the Client Secret permissions above.

Workspace Controls

Team Settings includes three workspace-level controls for this module:

• Enable Client Secrets: turns the feature on for the workspace.
• Restrict Client Secrets to assigned users: requires direct assignment or dynamic access unless the member has an all-secrets permission.
• Require email verification to reveal secrets: forces a step-up verification code before sensitive fields can be revealed.

Recommended Internal Explanation

If you are documenting this for your team, the clearest explanation is: Client Secrets are structured secure records for operationally sensitive data. Templates define the field layout, secrets hold the real values, access can be direct or rule-based, and sensitive fields require an intentional reveal step instead of showing up automatically in ticket content.