Salesforce terms starting with K

A Key Derivation Function (KDF) is a cryptographic primitive that derives one or more secondary keys from a primary input, typically a master key, a password, or a passphrase. KDFs are designed to be one-way and computationally expensive, making them resistant to brute-force attacks on the underlying input. In the Salesforce context, KDFs underpin password hashing (the platform never stores plaintext passwords; it stores KDF-derived hashes), tenant secret derivation (Shield's data encryption keys derive from the tenant secret through a KDF), and various API token generation paths. The KDF concept matters in Shield Platform Encryption because the visible tenant secret is not what actually encrypts records; the platform derives per-record or per-context data encryption keys through a KDF chain from the tenant secret. This separation lets the platform rotate keys without re-encrypting all data: rotation changes the tenant secret, but only new writes use the new derived keys. Older data remains decryptable with the original derivation chain until a Mass Encryption job re-derives.

Key Management in Salesforce is the set of administrative operations that control the cryptographic key material behind Shield Platform Encryption. Those operations include generating a new tenant secret, importing customer-supplied key material for Bring Your Own Key, configuring an external or Cache-Only key service, rotating the active secret, exporting secrets for backup, and destroying retired or compromised secrets. The work happens on the Key Management page inside Encryption Settings in Setup. The platform handles the cryptographic mechanics for you. It derives data encryption keys, generates initialization vectors, and produces ciphertext without exposing those details to the administrator. Your job is the lifecycle: deciding when a key rotates, who is allowed to touch it, and proving to auditors that policy was followed. Because destroying a key can make the data under it permanently unreadable, key management is the highest-stakes administrative responsibility in any org that runs Shield.

A Key Pair is the mathematical pairing of a public key and a private key used in asymmetric cryptography (also called public-key cryptography). The public key can be shared openly and is used to encrypt data or verify signatures; the private key is kept secret and is used to decrypt data or generate signatures. The pair is generated together such that operations performed with one can only be reversed with the other: data encrypted with the public key requires the private key to decrypt, and signatures made with the private key can only be verified with the matching public key. In Salesforce, key pairs underpin several integration patterns. JWT-based OAuth flows use key pairs: Salesforce holds the public key to verify the JWT signature; the integration holds the private key to sign the JWT. SAML SSO uses key pairs for signature verification: the Identity Provider signs assertions with a private key; the Service Provider verifies with the matching public key. Mutual TLS (mTLS) for callouts uses key pairs to authenticate both client and server. Understanding the asymmetric model is foundational for any Salesforce integration architecture work.

Key Tenant Secret Rotation is the Salesforce Shield Platform Encryption operation of generating a new tenant secret so it becomes the active key material, while the previous secret is archived and kept available to decrypt older data. Salesforce calls this key rotation because the new tenant secret derives new data encryption keys, and every write after the rotation uses them. The work happens in Setup under Encryption Settings, in the Key Management view, using the Generate Tenant Secret button. Rotation by itself is fast and non-disruptive. New records encrypt under the new active secret, and reads of older records keep decrypting under the archived secret, so nobody notices a change. To move existing data onto the new key you run the background encryption service, which re-encrypts records under the active secret. The Status column in Key Management labels each secret Active, Archived, or Destroyed, and that lifecycle is the heart of the practice.

A Knowledge Action is a configurable button on a Knowledge Article record that runs a defined operation: publish, archive, edit as draft, submit for translation, restore a previous version, or invoke a custom Flow. Knowledge Actions sit in the Article Actions section of the page layout and control how editors and reviewers progress an article through its publishing lifecycle. Beyond the standard actions Salesforce ships, admins can build custom Knowledge Actions that trigger Flows for review workflows, compliance approvals, or batch operations on related articles. Knowledge Actions exist because the Knowledge publishing workflow has more states and transitions than typical sObjects. A Knowledge Article moves through Draft, Pending Translation, Published, Archived, and Edit as Draft states, with each transition requiring specific permissions and triggering different downstream effects (search indexing, channel visibility, translation queuing). Knowledge Actions are the UI surface for those transitions, giving editors a buttoned workflow instead of a manual status update sequence. Without them, the publishing lifecycle becomes a series of error-prone field edits.

A Knowledge Agent in Salesforce is a service user who creates, edits, publishes, archives, and translates Knowledge articles. The name is an older, informal label for the person who authors the knowledge base. Salesforce documentation today usually calls this person a Knowledge author or a Knowledge User, because "agent" now also describes Agentforce AI agents that read the same articles. The role lives in Salesforce Knowledge, the Service Cloud feature that stores articles on the standard Knowledge object. A Knowledge Agent needs a Knowledge User feature license plus object and special permissions, granted through a permission set or profile. The label is legacy, but the work it describes (writing trusted answers that reps, customers, and AI agents reuse) is very much current.

A Knowledge Article is a structured record in Salesforce that stores a reusable answer, procedure, or piece of reference content. Articles live on the KnowledgeArticleVersion object and follow a publishing lifecycle of Draft, Published, and Archived. Each article belongs to a record type that controls its fields and template, gets categorized by data categories or topics, and renders in the agent console, Experience Cloud sites, the Salesforce Mobile App, and Einstein Bot conversations. Articles are versioned, multilingual, and channel-aware. Versioning means an editor can take a published article into a new draft, change it, and republish without breaking links. Multilingual means the same article can have a primary version in English and translated versions in French, Spanish, or any language the org licenses. Channel-aware means each article can be marked visible to internal users, partners, customers, or public sites independently. The combination is what makes Knowledge the deflection engine for Service Cloud rather than a plain content store.

Knowledge Article Version is the actual content record in Salesforce Knowledge. Each Knowledge Article is a container that holds multiple versions: draft versions in progress, the one Online published version visible to users, and archived versions from past publish cycles. The Version record carries the title, body, fields, channel availability, and translation linkage; the parent Article record is just an ID and metadata wrapper. The version model is what lets Salesforce Knowledge separate the "what is published right now" from "what is being edited" without breaking links or search indexes. A Version moves through three states: Draft (editable), Online (published, read-only), Archived (no longer published). At any moment one Version is Online and any number can be Draft or Archived. Republishing creates a new Version, demotes the previous Online version to Archived, and updates the parent Article's pointer.

Knowledge One is the unified Knowledge widget in the Salesforce Classic agent console, predecessor of the Lightning Knowledge Sidebar. It combined article search, article attach, and article share into a single sidebar panel inside the Classic Service Console. Knowledge One let agents see articles relevant to the active case, attach them, and send them to customers without leaving the case context. It was the original implementation of the agent-facing Knowledge integration that Lightning Knowledge later modernized. Knowledge One is a Classic-era term. In Lightning Experience, the equivalent is the Knowledge Sidebar component placed through Lightning App Builder. Most current Service Cloud deployments run Lightning Experience and use the Sidebar component; Knowledge One persists primarily in legacy Classic implementations that have not migrated. The term still appears in Salesforce Help documentation and older Trailhead modules, so understanding it helps when reading legacy material or supporting customers on older orgs. New deployments should use Lightning Knowledge with the Knowledge Sidebar instead.

Knowledge Settings is the Setup page where admins enable and configure Salesforce Knowledge org-wide. The page controls whether Lightning Knowledge is active, the default knowledge language, multilingual support, search behavior, view tracking, and the various article authoring permissions. The path is Setup, Knowledge Settings. Every option chosen here applies to the entire org, and several settings are one-way decisions that cannot be reversed once flipped. Knowledge Settings is the master configuration for the broader Knowledge feature. Enabling Lightning Knowledge here unlocks the KnowledgeArticleVersion object, the publishing lifecycle, and the agent and customer-facing surfaces. Disabling specific features (article voting, anonymous voting, search highlights) shapes the experience without affecting the data model. Most settings are configured during the initial Service Cloud rollout and revisited only when adding multilingual support or tightening the editorial workflow.

The Knowledge Sidebar is the Lightning component that surfaces Salesforce Knowledge articles inside the Service Console, sitting in the right rail of the case page and the chat console. It runs an auto-suggest query against the case Subject and Description (or against active chat keywords), ranks matching articles, and presents the top results inline with attach, send, and link actions. Agents see relevant articles without leaving the case context, attach them with one click, and increment article view and ranking counters automatically. The Knowledge Sidebar is the agent-facing surface that turns Salesforce Knowledge from a library into a deflection engine. Without it, agents have to navigate to the Knowledge tab, search manually, find an article, copy its content, and paste into the case. With the Sidebar, the article is suggested as soon as the case opens, attached with a click, and shared with the customer through email or chat. The productivity difference is meaningful at scale; a Service Cloud team with the Sidebar configured typically deflects 30 to 50 percent more cases through Knowledge than a team without it.