> For the complete documentation index, see [llms.txt](https://flapjax.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://flapjax.gitbook.io/docs/settings/workspace/consents.md). # Consents A **consent** is a purpose you send under: Marketing, Promotions, Product news, Account & legal. Rather than one blunt "can we email this person?", you define the reasons you contact people. Each recipient then decides which reasons they accept, per channel. Every email and SMS action can declare the consent it sends under. At send time Flapjax checks that the recipient allows that purpose on that channel and skips anyone who does not. Recipients manage their own choices on your [unsubscribe page](/docs/settings/workspace/unsubscribe-pages.md), which turns into a preference centre listing every consent you have defined. Consents cover **email and SMS**. Other channels answer to their channel switch alone. *** ### Viewing consents The list shows each consent with the channels it covers and its default. An **Always on** tag marks consents nobody can refuse, and an **Archived** tag marks retired ones. Turn on **Show archived** to include retired consents. *** ### Creating a consent Click **New consent** and fill in: * **Name**, what recipients see on your preference page, such as "Marketing". * **Description**, optional helper text under the name on that page. * **Channels**, whether this purpose covers Email, SMS or both. * **Opted in by default**, the state for people who have never answered. Covered below. * **Always on**, for mail people cannot opt out of. Covered below. * **Display order**, which sets the order on the preference page and in pickers. Flapjax derives a **key** from the name, so `Marketing` becomes `marketing`. The API and your CSV import and export columns use that key. It stays fixed once the consent exists, since stored answers and import files reference it. Renaming the consent later changes what people see and nothing more. *** ### Defaults: what happens before anyone answers Flapjax never invents an answer. A person who has not chosen takes their state from the consent's **Opted in by default** setting. * **Off**, meaning opted out by default. Nobody receives this purpose until they opt in. The safest choice for marketing. * **On**, meaning opted in by default. Everyone receives it until they opt out. You can add a new consent without touching a single person record. The default decides, and individual answers override it as they arrive. {% hint style="warning" %} A new consent with **Opted in by default** turned on starts sending that purpose to people who previously opted out of everything. Their earlier choice could not cover a purpose that did not exist yet. Pick an opt-out default when you are not certain. {% endhint %} *** ### Always on: mail that cannot be refused Some messages rest on no consent at all. Password resets, security notices, account closure, notifications the law requires you to send. Mark those **Always on** and Flapjax treats them differently: * They appear on the preference page as read-only **"Always on"** with no checkbox. * Nobody can refuse them through the preference page, the API or an import. * They **still reach people who have unsubscribed**, including anyone who used "Unsubscribe from everything" or their mail client's one-click unsubscribe. An Always on consent is opted in by default and covers every channel, so Flapjax switches off the channel list as you turn it on. {% hint style="info" %} Use Always on sparingly and only for mail that is genuinely not marketing. Anything a person could reasonably expect to opt out of belongs in an ordinary consent. {% endhint %} *** ### Archiving and deleting **Archiving** retires a consent and keeps every answer people gave. It leaves action pickers and preference pages, historic answers stay on record, and messages already sent under it keep their tag in reporting. This is the normal way to retire a purpose. **Deleting** removes the consent and every stored answer, permanently. Save it for a consent you created by mistake. *** ### Using a consent on a send Email and SMS actions carry a **Consent** picker. You find it in the automation builder's Send Email and Send SMS actions, and in the Send Email and Send SMS actions on the People page. Choose the purpose the message goes out under. Only people who allow it on that channel receive it. Leave the picker empty and the send behaves as it always did, gated by the channel switch alone. Your existing automations carry on untouched until you assign a consent to them. *** ### How consent is decided at send time For each recipient, Flapjax checks whether they allow the action's consent on that channel. Someone who never answered falls back to the consent's default. **Always on** consents allow the send outright. An action with **no consent assigned** answers to the person's channel summary instead: Email Consent or SMS Consent, which stays on as long as they allow at least one consent on that channel. Anyone blocked gets skipped before the message reaches your provider. Flapjax records the skip and its reason in [communications reporting](/docs/reporting/communications.md), so a run that dropped people stays visible rather than silent. *** ### Where people's answers live * **Preference page.** Recipients manage their own choices. See [Unsubscribe Pages](/docs/settings/workspace/unsubscribe-pages.md). * **Person detail page.** The Details sidebar carries a **Consent purposes** section with a row per consent and channel, editable on their behalf. * **Import and export.** People CSVs carry a `consent__` column per purpose, such as `consent_marketing_email`. An empty cell leaves the person on the default rather than writing a refusal. * **Segments and reports.** The same columns work as filter fields, so you can build an audience from "allows Marketing email". *** ### The starter consent Every workspace starts with one consent per channel marked as that channel's **default**, created for you as **Email updates** and **SMS updates**. It holds the consent people had before consents existed, and it catches a direct write of `email_consent` or `sms_consent`. See [Consent & subscriptions](/docs/your-data/people/consent-and-subscriptions.md#writing-email-consent-directly). Rename it to suit your workspace. Prefer people to see only your own consents? Keep it and give it a fitting name rather than deleting it. It anchors legacy writes and imports that carry `email_consent`. *** ### Related * [**Unsubscribe Pages**](/docs/settings/workspace/unsubscribe-pages.md), the preference centre recipients use to set their own consents. * [**Consent & subscriptions**](/docs/your-data/people/consent-and-subscriptions.md), covering how consent gates delivery and how the channel switches work. * [**Communication actions**](/docs/automations/actions/communication.md), covering how you assign a consent to a Send Email or Send SMS action. * [**Communications reporting**](/docs/reporting/communications.md), covering how you filter delivery reports by consent.