Consent and GDPR records

Kepler keeps consent as a record, not a checkbox: one entry per person and purpose saying what they agreed to, on what legal basis, when, and until when — plus every withdrawal. An auditor asks "show me the history"; a yes/no field cannot answer that. This article covers the workspace switch, what it hides, the opt-out layer that is always on, purposes and expiry, and the job-board setting.

The Consent tracking switch

Settings → Privacy & consent opens with a single switch, Consent tracking. It is off by default for every workspace. A desk in a country where GDPR does not apply should not have to look past consent rows, columns and filters it will never use, so nothing about positive consent appears until an admin turns it on. Turning it on later loses nothing: opt-outs recorded in the meantime (below) are already in the ledger and show up immediately.

The page is visible to anyone who can edit workspace settings; the sections beneath the switch stay greyed out until it is on.

What is hidden while it is off

• The Consent row in a candidate's or contact's Details sidebar, the consent side sheet it opens, and the Record consent / Record opt-out entries in the record's ⋯ menu.
• The consent header badge, the Consent column, the consent filter and the two saved views (Expiring consent, Expired consent).
• The "no marketing consent" bucket in campaign audience previews, the bulk Record consent action, and the Consent group in CSV import mapping.
• The nightly expiry sweep, the weekly inbox digest, and the consent entries in the automations pickers.

Turning the switch off again hides these surfaces; the ledger itself is kept, withdrawals keep blocking, and everything returns when it is switched back on.

Opt-outs are always recorded

Every jurisdiction has an opt-out law even where GDPR does not apply, so the opt-out half of the model does not depend on the switch. Whether it is on or off:

• A click on a campaign unsubscribe link writes a withdrawal for Marketing · email.
• A WhatsApp STOP reply writes a withdrawal for Marketing · WhatsApp.
• Campaign enrolment, audience previews and the send-time check treat a withdrawn person as opted out and skip them — this cannot be turned off.
• Withdrawals appear on the person's History tab as they happen.

Do not contact is separate and unchanged: it is the record-level hard stop across every channel, shown beside consent and never merged with it. Setting it writes no consent record.

Purposes

Consent is recorded per purpose. Every workspace has four system purposes — Recruiting, Marketing · email, Marketing · SMS and Marketing · WhatsApp — each with a default validity of 24 months that you can change. You can add custom purposes (label, channel, whether it counts as marketing, default validity) and archive them once they have been used; system purposes can be relabelled but not removed.

Each record carries a lawful basis — consent, legitimate interest, contract or legal obligation — a source (form, email, verbal, portal application, import, API and so on), the date it was given and the date it runs out, and optional evidence such as a note or the message it came from. Records are never edited or deleted. A mistake is voided with a reason by a workspace admin, and the void stays in the history.

Most agencies process candidates under legitimate interest. The default recruiting basis setting records that for you, and Kepler never blocks recruiting activity for want of consent.

Expiry flags — it never deletes

A consent record with a validity date becomes expiring inside the warning window (30 days by default, set on the same page) and expired after it. Both are computed when you look, so changing the window changes what you see immediately. Every night Kepler flags each transition once: a timeline entry on the record, a consent.expiring or consent.expired webhook event, and — on Mondays — one inbox digest to workspace admins with the count by purpose and a link to the Expiring consent view. Records that lapse also reach their owner's inbox individually.

Turn on Require consent for marketing to make campaign enrolment and sends require a valid marketing record for the channel; a campaign audience whose lawful basis is consent requires it on its own. Without either, only withdrawals block.

The job-board setting

Under Job board on the same page, choose how your apply form treats consent. It is a three-way choice, default Off:

• Off — the form keeps today's "By applying you agree…" note and writes nothing.
• "Keep me informed" box only — adds one unticked checkbox; ticking it records Marketing · email consent from the application.
• Required storage consent — adds a required checkbox with your own wording and privacy link (Recruiting consent is recorded on every application) plus the optional marketing box. Submit is blocked until the required box is ticked.

The wording you publish is versioned with each record, so changing it later never orphans consent already given. This setting can only be changed while Consent tracking is on.

Where else consent shows up

• Lists — the Consent column and filter (any purpose or one, by state), and the two saved views.
• Import — map columns such as marketing consent, consent date or lawful basis into the ledger instead of a text field.
• The Assistant — "record that Ada consented to marketing emails" proposes a consent record for you to confirm; "who has marketing consent expiring this month" is an ordinary filtered question.
• API and webhooks — see API & webhooks: the consents:read / consents:write scopes, /consents, and the four consent.* events. API writes land whether or not the switch is on.