<SYSTEM>This is the full developer documentation for Pural</SYSTEM>

# Getting started

> Create an account, set up your organization's branding, and write your first proposal.

Pural is a proposal builder. You assemble a document from **sections**, share it with a client as a link or a PDF, and see how they read it. This page takes you from an empty account to a proposal you can send.

## Create your account

[Section titled “Create your account”](#create-your-account)

Sign up with an email address and a password, or with a Google or Microsoft account. If a colleague invited you, open the invitation link instead — you will join their workspace rather than creating a new one.

New accounts get a verification email. Until you confirm it, Pural keeps you on the verification screen; you can resend the mail from there.

## Set up your brand

[Section titled “Set up your brand”](#set-up-your-brand)

First-time sign-ups go through a short onboarding wizard:

1. **Welcome** — name your workspace. This is the organization every proposal, customer and template belongs to.

2. **Your brand** — enter your website domain and choose **Analyze**. Pural reads the site and prefills your logo, brand colors and font; it takes around 20 seconds, and everything it fills in stays editable. If the scan fails or only partly succeeds, fill in the rest by hand — nothing depends on it having worked.

   You also pick an **industry** here, which Pural uses to suggest matching templates.

3. **Invite** — add colleagues by email, or skip and do it later from the organization settings.

4. **Done** — a summary of what you set up, and a link to the dashboard.

Everything from this step lives in [Branding](/en/settings/branding/) afterwards, so nothing here is a one-time decision.

## Write your first proposal

[Section titled “Write your first proposal”](#write-your-first-proposal)

1. **Add the customer.** Choose **Create Proposal** and either pick an existing customer, create a new one inline, or continue with **No customer** and attach one later. The customer is what fills in [placeholders](/en/proposals/placeholders/) like the company name, so attaching one early saves retyping.

2. **Pick a starting point.** Start from **Blank page**, or from one of your templates — the template’s sections are copied into the new proposal, so editing them changes nothing in the template itself.

3. **Write the content.** The [editor](/en/proposals/editor/) opens on the proposal. Add sections, split them into columns, and fill the cells with text, images and buttons.

4. **Add pricing.** A [price section](/en/proposals/pricing/) holds the line items as a structured table rather than as typed-out text, so the totals add up on their own.

5. **Share it.** Create a share link and send it, or send the proposal by email from your own address. Both are covered in [Sharing](/en/sending/email/).

## What to read next

[Section titled “What to read next”](#what-to-read-next)

* [Sections](/en/proposals/sections/) — the unit everything else sits inside
* [Text, image and button blocks](/en/proposals/blocks/) — what goes in a section
* [Templates](/en/library/templates/) — so the second proposal is faster than the first

# Proposals that look like the work you sell

> A proposal is the first real artifact a client gets after the call. Pural makes that artifact carry its weight — as a page the client reads, not a file they file away.

Write it once

Build a proposal from sections, save the good ones as templates and reusable blocks, and start the next one from something already written.

[Templates and blocks →](/en/library/templates/)

Send it as a page, not a file

Share a link and the client reads a real page in the browser — or export the same proposal as a PDF when they want a file.

[What the client sees →](/en/sending/public-page/)

See what happened next

Opens, time spent, which sections were actually read and what was clicked — per recipient, without cookies.

[Proposal analytics →](/en/proposals/analytics/)

Let an assistant draft it

Connect Claude or any MCP client to your workspace and have it interview you, outline the proposal and write the sections.

[Connect an AI client →](/en/ai/connect/)

# Drafting with AI

> Run the guided interview, review the outline, and let the assistant write the sections, the price table and the acceptance block into your workspace.

Once an AI client is [connected](/en/ai/connect/), it can draft proposals directly in your workspace. The useful part is not that it writes text — it is that it writes into the real structure, using your real templates.

## The guided flow

[Section titled “The guided flow”](#the-guided-flow)

Pural ships a prompt that runs the whole thing. In Claude Code it appears as `/pural:draft_proposal`; other clients list it among the server’s prompts. You can pass what you already know as a brief, and it will not ask about that again. There is a second prompt for building templates — see below.

It runs in four steps:

1. **Orientation.** The assistant reads your workspace — your templates, your reusable blocks and your recent proposals — so it can suggest real options instead of asking in the abstract.
2. **Interview.** A short conversation about the client, the goal, the scope and what is explicitly out of it, the timeline, the pricing shape, and how formal the tone should be. It drills down where an answer is too thin to write a section from.
3. **Outline.** It presents the proposal section by section and **stops**. Nothing is written to your workspace until you say go.
4. **Writing.** It creates the proposal and adds the sections, reusing your blocks rather than rewriting boilerplate, and checks its own layout afterwards.

## What it can write

[Section titled “What it can write”](#what-it-can-write)

Most of the proposal, including the two parts that are structured data rather than prose:

* **The price table.** The assistant supplies the line items — description, quantity, unit price, discounts, tax — and Pural computes every subtotal and total on read. It never writes a total itself, so the numbers cannot go stale.
* **The acceptance block.** Button text, the form behind it, an optional decline link and whether accepting produces a signed PDF. Its defaults are English; the assistant is told to supply the texts in the proposal’s language.
* **Images.** It can search stock photography and place a result, and it can reference an asset you already uploaded. See [Images in a proposal](/en/proposals/images/).

## What you still do yourself

[Section titled “What you still do yourself”](#what-you-still-do-yourself)

The assistant hands the proposal back with a list of what is left. Expect these:

* **Attaching the customer**, if you did not give it a customer ID.
* **Uploading your own images.** It can place a stock photo or an asset that already exists, but it cannot upload a file into your workspace.
* **Sending.** Always yours, deliberately: an assistant that reads a document it did not write should not also be able to mail it to your client.

Two things to check in what it wrote

**Invented facts.** The prompt forbids inventing prices, dates, headcounts, client names and references, and requires a `[TODO]` marker where something is missing. Search the draft for `[TODO]` before you send it.

**Braces in the text.** A real [placeholder](/en/proposals/placeholders/) showing `{{customer.name}}` means its value is missing — usually no customer attached yet. Text somebody typed that merely looks like one never resolves at all. Either way, braces in a proposal you are about to send are something to fix.

## Building a template instead

[Section titled “Building a template instead”](#building-a-template-instead)

The second prompt, `/pural:draft_proposal_template`, builds a reusable [proposal template](/en/library/templates/) rather than one proposal. Same four steps, different questions — there is no client to ask about, and that is the point:

* **Which sections** this kind of offer always needs, as opposed to the ones you would rather add case by case.
* **Where the content comes from**: your own words, one of your [reusable blocks](/en/library/blocks/), or a page of your own website. Give it URLs — your services page, your process page — and it reads them as source material to rewrite, not to paste.
* **What the price table has to be able to express**: unit positions, a rate per hour or day, an optional add-on, a note row, a discount. It builds one example of each so the shape is there when you fill in the real numbers.
* **How acceptance works**: the button text, which fields the form asks for, whether a decline link is offered, and whether accepting has to produce a signed PDF.

Everything that would differ per client becomes a [placeholder](/en/proposals/placeholders/) rather than text. Afterwards, check the template for the opposite failure: a client detail written out as literal text reads perfectly well and is invisible until it reaches the wrong client.

## Working without the guided prompt

[Section titled “Working without the guided prompt”](#working-without-the-guided-prompt)

You do not have to use the prompt. You can simply ask the assistant to read a proposal, rewrite a section, reorder things or copy a structure from an earlier proposal, and it has the tools for that. The prompt exists because the failure mode of AI-written proposals is almost never bad prose — it is missing input.

# Connect an AI client

> Point Claude or any MCP client at your Pural workspace over MCP, and choose which permissions it gets.

Pural hosts an **MCP server**. Any client that speaks the Model Context Protocol — Claude Code, Claude Desktop, or another MCP client — can connect to your workspace and work on proposals in it.

## The endpoint

[Section titled “The endpoint”](#the-endpoint)

Add Pural as an MCP server in your client using the `/api/mcp` endpoint of your Pural installation, for example `https://app.pural.io/api/mcp`.

Your client opens a browser window, you sign in to Pural as usual, and a consent screen names the application and the permissions it is asking for. Approving it sends you back to the client, connected.

## Permissions

[Section titled “Permissions”](#permissions)

Permissions are granted per resource, and the consent screen names the ones being requested:

| Permission          | What it allows                                                                                         |
| ------------------- | ------------------------------------------------------------------------------------------------------ |
| **Read proposals**  | List and read proposals, sections, templates and blocks                                                |
| **Write proposals** | Create proposals, and add, edit, reorder and remove sections — including price and acceptance sections |
| **Read customers**  | Search your customer list and read a customer record                                                   |
| **Write customers** | Create a new customer                                                                                  |

Customer *contacts* — the named people and their details — are not reachable over MCP at any permission level. An assistant can attach a company to a proposal; it cannot read the people at it.

What an assistant can never do

Some things are deliberately out of reach over MCP, whatever the assistant asks for and whatever permissions were granted:

* **Sending email.** Sending stays a decision you make in the app. An assistant reads documents it did not write, so it should not also be able to mail one to your client.
* **Uploading files.** It can place a stock photo or an asset that already exists, but it cannot put a file into your workspace.
* **Editing or deleting a customer.** Creating one is allowed; changing your existing CRM records is not.
* **Inserting placeholders.** See [Placeholders](/en/proposals/placeholders/).

For the full list of what an assistant can call, see [What an assistant can do](/en/ai/tools/).

## Which workspace it reaches

[Section titled “Which workspace it reaches”](#which-workspace-it-reaches)

The connection is bound to the organization you were signed in to when you approved it. If you belong to several, connect while in the right one — and if you later leave that organization, the connection stops reaching its data.

Writes also need an active subscription, the same as in the app: an assistant cannot write proposals during an expired [trial](/en/settings/billing/).

## Disconnecting

[Section titled “Disconnecting”](#disconnecting)

Connected applications are listed in your account settings and can be revoked there. Revoking stops the client from getting new access, and it does not touch anything the assistant already wrote.

Caution

An access token the client already holds keeps working until it expires, which can be up to an hour after you revoke. If a connection needs to stop reaching your data *right now*, revoking is not sufficient on its own.

# What an assistant can do

> The full list of MCP tools a connected AI client can call — add_section, add_price_section, add_accept_section, render_preview, find_images, fetch_page_content and the rest — what each one touches, and the things none of them can.

A [connected](/en/ai/connect/) AI client gets a fixed set of tools. This is all of them. You never call these yourself — the list is here so you know what a client can reach, and what it cannot.

## Reading

[Section titled “Reading”](#reading)

| Tool                    | What it returns                                                                                                                 |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| `get_authoring_context` | Your templates, reusable blocks, recent proposals and brand colours, plus the exact section format. Assistants call this first. |
| `search_docs`           | This documentation.                                                                                                             |
| `list_proposals`        | Your proposals, newest first, filterable by status and free text.                                                               |
| `get_proposal`          | One proposal with all its sections.                                                                                             |
| `list_sections`         | A proposal’s or template’s sections with a text preview and the placeholders each uses, without the full layout tree.           |
| `render_preview`        | A layout report and screenshots of what a section actually looks like.                                                          |
| `list_templates`        | Your proposal template library.                                                                                                 |
| `get_proposal_template` | One template with its sections and the placeholders it actually contains.                                                       |
| `list_placeholders`     | Every [placeholder](/en/proposals/placeholders/) that exists, with the markup to insert it.                                     |
| `fetch_page_content`    | The text of a public web page — your own services or process page — as source material.                                         |
| `list_template_blocks`  | Your reusable blocks.                                                                                                           |
| `get_template_block`    | The sections inside one block.                                                                                                  |
| `get_price_table`       | The line items of a price section, without the computed totals.                                                                 |
| `get_accept_section`    | The acceptance configuration: button, form fields, decline link, signature flag.                                                |
| `find_images`           | Stock photo candidates, returned as actual pictures.                                                                            |
| `list_customers`        | Your customer list, searchable.                                                                                                 |
| `get_customer`          | One customer record.                                                                                                            |

## Writing

[Section titled “Writing”](#writing)

Every tool below needs the write permission **and** an active subscription — the same gate the app applies. During an expired [trial](/en/settings/billing/) an assistant can still read, but not write.

| Tool                       | What it changes                                                         |
| -------------------------- | ----------------------------------------------------------------------- |
| `create_proposal`          | Creates a draft, optionally from a template.                            |
| `create_proposal_template` | Creates an empty [proposal template](/en/library/templates/).           |
| `add_section`              | Inserts a section at a position you choose, or at the end.              |
| `update_section`           | Replaces one section. It cannot change a section’s kind.                |
| `remove_section`           | Deletes one section.                                                    |
| `reorder_sections`         | Sets the order. Must list every section exactly once.                   |
| `add_price_section`        | Creates a price section with its line items.                            |
| `set_price_table`          | Replaces a price table’s line items.                                    |
| `add_accept_section`       | Creates the acceptance block. One per proposal or template.             |
| `set_accept_section`       | Replaces the acceptance configuration — it replaces rather than merges. |
| `create_customer`          | Creates a customer. This writes real CRM data.                          |

Totals are never written

For a price table an assistant supplies only line items — description, quantity, unit price, discounts, tax. Pural computes every subtotal, discount, tax line and grand total when the proposal is read. A typed total would go stale the moment a line above it changed, so none is ever stored.

The same tools edit templates

Every section tool takes either a `proposalId` or a `proposalTemplateId`, never both. A [template](/en/library/templates/) holds exactly the same sections as a proposal, so an assistant builds one with the same `add_section`, `add_price_section` and `add_accept_section` calls — the difference is in the text, where anything client-specific becomes a [placeholder](/en/proposals/placeholders/).

## The guided prompts

[Section titled “The guided prompts”](#the-guided-prompts)

Alongside the tools, the server offers two prompts. In Claude Code they appear as `/pural:draft_proposal` and `/pural:draft_proposal_template`. See [Drafting with AI](/en/ai/authoring/).

## What no tool can do

[Section titled “What no tool can do”](#what-no-tool-can-do)

These limits hold regardless of which permissions were granted:

* **Sending.** No tool sends email. Sending stays a decision you make in the app.
* **Uploading.** An assistant can place a stock photo or an asset that already exists, but it cannot put a file into your workspace.
* **Deleting a template.** It can create and edit proposal templates; it cannot delete one. Other proposals were built from it, so that stays a decision you make in the app.
* **Editing customers.** It can create one and read the list; it cannot change or delete an existing record, and customer *contacts* are not exposed at all.

# Customers

> Companies, their contacts and addresses — and how attaching one to a proposal feeds its placeholders.

A customer is the company a proposal is for. Contacts are the people at that company, and they are what you actually send a proposal to.

## The customer record

[Section titled “The customer record”](#the-customer-record)

**General** holds the company itself: name, address and the details that appear on the proposal.

**Contacts** holds the people — name, email address and phone number. A customer can have several, which matters because the person you talk to is often not the person who signs.

Addresses have structured fields — street, house number, addition, postal code, city, country — so they format correctly wherever they appear rather than being one free-text blob.

## Why attach one to a proposal

[Section titled “Why attach one to a proposal”](#why-attach-one-to-a-proposal)

Two things depend on it:

* [Placeholders](/en/proposals/placeholders/) fill in from the attached customer. Without one, there is nothing to resolve them against.
* The [send dialog](/en/sending/email/) offers that customer’s contacts as recipients instead of asking you to retype an address.

You can create a proposal with **No customer** and attach one later — the placeholders resolve once you do.

## Creating one

[Section titled “Creating one”](#creating-one)

Create customers from the customer list, or inline while creating a proposal, which saves leaving the flow just to add a name and an email.

# Reusable blocks

> Keep the sections you write in every proposal — about us, terms, references — in one place and insert them.

A reusable block is one or more finished sections you can drop into any proposal. It is where the boilerplate lives: the team introduction, the terms, the case studies, the “how we work” section.

## Creating one

[Section titled “Creating one”](#creating-one)

A block has a **title**, a **description** and a **category**, and holds its sections built in the same editor as everything else. The description is what distinguishes two similar blocks in the list, so write it for the colleague choosing between them.

Categories group the library — for example by purpose (intro, proof, terms) or by service line. Blocks without one appear under **Other**.

Like templates, blocks can be **active** or inactive. Inactive blocks stay in the library but disappear from the insert list.

## Inserting one

[Section titled “Inserting one”](#inserting-one)

**Library** in the editor toolbar opens the block library, searchable by title and description. Inserting a block copies its sections into the proposal at your chosen position.

The copy is one-way, exactly as with templates: editing the inserted sections does not change the block, and updating the block does not rewrite proposals that already use it. That is deliberate — a sent proposal should not change retroactively because someone edited a block — but it does mean a wording fix has to be made in the block *and* in any draft that already carries the old text.

## What makes a good block

[Section titled “What makes a good block”](#what-makes-a-good-block)

Blocks earn their keep when they are self-contained. A section that only makes sense after a specific preceding section is a source of confusion in a library; the team introduction, the guarantee, the terms and the reference list are the sort of thing that reads correctly wherever it lands.

# Proposal templates

> Save a proposal's structure as a template so the next one starts written rather than blank.

A template is a proposal skeleton: the sections you use every time, in the right order, with the wording that does not change already written and [placeholders](/en/proposals/placeholders/) where it does.

## Creating one

[Section titled “Creating one”](#creating-one)

Create a template from the template list and build it in the same editor you use for proposals — same sections, same blocks, same settings. A template has its own **name** and **description**; the description is what your colleagues see when picking one, so “Retainer, monthly, for existing clients” beats “Template 3”.

Templates can be marked **active** or inactive. Inactive ones stay in the list for reference but drop out of the picker, which is how you retire last year’s pricing without deleting the history.

## Using one

[Section titled “Using one”](#using-one)

When creating a proposal, pick a template and its sections are **copied** into the new proposal. From that point the two are independent: editing the proposal never touches the template, and improving the template never rewrites a proposal already sent.

The picker separates **your templates** from **more templates** — a catalogue Pural suggests based on the industry you chose during onboarding.

## Building one with AI

[Section titled “Building one with AI”](#building-one-with-ai)

A [connected assistant](/en/ai/authoring/) can build a template for you: run `/pural:draft_proposal_template` and it asks which sections this kind of offer always needs, which of your blocks or which pages of your own website should feed them, what the price table has to be able to express, and how acceptance should work. Everything client-specific becomes a [placeholder](/en/proposals/placeholders/).

It can create and edit templates but never delete one — proposals have been built from it, so that stays with you.

## Templates or blocks?

[Section titled “Templates or blocks?”](#templates-or-blocks)

Both live in the [library](/en/library/blocks/), and the difference is scope:

* A **template** is a whole proposal — use it as a starting point.
* A **reusable block** is one or more sections — insert it into a proposal you are already writing.

Your standard “about us” belongs in a block. Your standard retainer offer belongs in a template. Putting “about us” in every template means updating it in every template.

# Proposals

> The proposal lifecycle in Pural: draft, share, accept — plus duplicating, versions and what each status means.

A proposal is one document for one customer. It starts as a private draft, becomes a shared snapshot the client can open, and ends up accepted, declined or expired.

## Status

[Section titled “Status”](#status)

The status follows what happens to the proposal rather than being picked from a list.

| Status       | What it means                                                        |
| ------------ | -------------------------------------------------------------------- |
| **Draft**    | Private. Only your team can see it; there is no working public link. |
| **Live**     | A share link exists and the client can open it.                      |
| **Sent**     | The proposal was emailed to at least one recipient.                  |
| **Viewed**   | A recipient opened the shared page.                                  |
| **Accepted** | A recipient accepted it on the public page.                          |
| **Declined** | A recipient declined it.                                             |
| **Expired**  | The link was marked expired; recipients see an expired notice.       |

## Sharing is a snapshot

[Section titled “Sharing is a snapshot”](#sharing-is-a-snapshot)

This is the part worth understanding before you send anything.

Creating a share link does not publish “the proposal” — it publishes a **frozen version of it**. Recipients keep seeing that version no matter what you change in the editor afterwards, so you can keep working without the document shifting under them.

That gives you three actions once something is shared:

* **Share new version** — takes a fresh snapshot and makes it the active one for recipients. Do this after you have made the edits you want them to see.
* **Back to editing** — withdraws the public version. The current link stops working and the proposal returns to draft.
* **Mark as expired** — the link stops working immediately and recipients see an expired notice instead of the proposal. This is for an offer that is genuinely no longer valid, not a way to hide a draft.

Previous versions stay listed, so you can tell exactly what a client was looking at when they replied.

## Change history

[Section titled “Change history”](#change-history)

Separately from what was shared, the editor keeps a history of your own saves. Open **Versions** to see recent ones with how long ago they happened, and **Restore** to go back to one. This is the safety net for a bad edit — not the same thing as the shared snapshots above.

## Duplicating

[Section titled “Duplicating”](#duplicating)

**Duplicate** copies a proposal, sections and all, as a new draft. It is the quickest way to reuse one specific proposal for a similar client. If you catch yourself duplicating the same proposal repeatedly, that is the signal to make it a [template](/en/library/templates/) instead.

## Deleting

[Section titled “Deleting”](#deleting)

Deleting a proposal is permanent, and it invalidates any share link that was created from it.

# Proposal analytics

> Who opened the proposal, how long they stayed, which sections they read and what they clicked.

Once a proposal has been shared, **Analytics** in the editor shows how it was actually read. This is the part a PDF attachment cannot tell you.

## What is measured

[Section titled “What is measured”](#what-is-measured)

| Metric               | Meaning                                                                   |
| -------------------- | ------------------------------------------------------------------------- |
| **Opens**            | How many times the shared page was opened                                 |
| **Sessions**         | Distinct visits, rather than raw page loads                               |
| **Active time**      | Time with the page actually in front of someone, not merely open in a tab |
| **Max scroll**       | How far down the proposal the reader got                                  |
| **Time per section** | Which sections held attention and which were skimmed                      |
| **Last viewed**      | When it was last opened                                                   |

Clicks are tracked by kind: the **accept button**, an **external link**, and a **PDF download**.

## Per recipient

[Section titled “Per recipient”](#per-recipient)

When a proposal was emailed to several people, the figures break down per recipient — opens, last viewed and active time for each. That is usually the more useful view: it tells you whether the person who actually decides has read it yet.

## Before anything is shared

[Section titled “Before anything is shared”](#before-anything-is-shared)

Analytics stays empty until the proposal has been shared or sent. There is nothing to measure on a private draft, and the panel says so rather than showing zeros.

## Privacy

[Section titled “Privacy”](#privacy)

Engagement is measured anonymously and **without cookies**, and only non-bot sessions count — link scanners in mail clients and security tools do not turn into phantom opens. The result is fewer, more honest numbers: an open in Pural is closer to a person than an open in a typical email tracker.

# Text, image and button blocks

> TextBlock, ImageBlock and ButtonBlock: the three content blocks you place inside a section, and every option each one offers.

Three blocks go inside a section’s cells. Everything you write in a proposal is one of them.

## Text (`TextBlock`)

[Section titled “Text (TextBlock)”](#text-textblock)

The text block is a rich-text editor: headings, paragraphs, bold and italic, lists, links and [placeholders](/en/proposals/placeholders/).

Paragraphs come in sizes, which is how you get fine print to look like fine print:

| Variant             | Use                                          |
| ------------------- | -------------------------------------------- |
| `t1`                | Body copy — the default                      |
| `t2`                | Small                                        |
| `t3`                | Caption-sized                                |
| `small` / `caption` | Muted fine print — but see the caution below |

Prefer t1, t2 and t3

`small` and `caption` render, as muted fine print, but the editor’s own type picker cannot produce them or select them again. Anyone who later edits that paragraph loses the variant without being told. Use `t3` for caption-sized text instead.

Headings are separate, from level 1 down to level 4, and get their size from the level rather than from a variant — a heading does not take a paragraph variant.

Quotes have their own style: a blockquote is what to use for a testimonial or a pulled-out client statement, rather than an italic paragraph.

Colour is worth one caution: leave the text colour alone and let [automatic contrast](/en/proposals/sections/#automatic-contrast) adapt it to the background.

## Image (`ImageBlock`)

[Section titled “Image (ImageBlock)”](#image-imageblock)

| Option                             | Values                                                                        |
| ---------------------------------- | ----------------------------------------------------------------------------- |
| **Source**                         | An asset you uploaded, or an external URL                                     |
| **Alt text**                       | Describes the image for screen readers and for when it fails to load          |
| **Fit** (`objectFit`)              | `cover` crops to fill, `contain` fits the whole image in, `fill` stretches it |
| **Aspect ratio** (`aspectRatio`)   | `auto` keeps the original, or force `1:1`, `4:3`, `16:9` or `3:4`             |
| **Alignment** (`alignment`)        | `left`, `center` or `right`                                                   |
| **Width** (`maxWidthPercent`)      | How much of the cell the image fills, `20`–`100` (default `100`)              |
| **Corner radius** (`borderRadius`) | `none`, `sm`, `md` (default), `lg` or `full`                                  |

The two sources are exclusive: either an uploaded asset, or an external URL. A block set to an external URL with no URL filled in falls back to asset mode rather than showing an error.

Uploaded images can be cropped and rotated in place, so you rarely need to prepare a file outside Pural first.

`cover` with a fixed ratio is the reliable choice when several images sit side by side: without it, images of different proportions make the row look ragged.

## Button (`ButtonBlock`)

[Section titled “Button (ButtonBlock)”](#button-buttonblock)

A call to action — book a call, open a document, reply.

| Option                               | Values                                             |
| ------------------------------------ | -------------------------------------------------- |
| **Label**                            | The text on the button                             |
| **Link type**                        | A web address, a phone number, or an email address |
| **Link target**                      | The URL, number or address itself                  |
| **Open in a new tab**                | For web links                                      |
| **Fill** (`backgroundColor`)         | Hex colour of the button itself                    |
| **Label colour** (`fontColor`)       | Hex colour of the text on it                       |
| **Padding** (`paddingX`, `paddingY`) | Horizontal `sm`–`xl`, vertical `sm`–`lg`           |
| **Font size** (`fontSize`)           | `sm`, `md` or `lg`                                 |
| **Corner radius** (`borderRadius`)   | `none`, `sm`, `md`, `lg` or `full`                 |
| **Alignment** (`alignment`)          | `left`, `center` or `right`                        |

Unlike text, a button’s colours are meant to be set. Automatic contrast does not reach them: a button on a dark section keeps whatever fill and label colour it was given, so check that the label is still legible against the fill you chose.

Fill, label colour, padding, font size and corner radius are offered in the editor as a few combined size presets. Setting them independently works and renders, but a combination outside those presets cannot be reproduced by hand afterwards.

A phone or email button opens the recipient’s own phone or mail app, which is worth knowing before you use one as the main call to action in a proposal that will mostly be read on a desktop.

# The editor

> How the proposal editor is laid out: sections, the content canvas, and the tools along the top.

The editor has two layers, and keeping them apart makes everything else easier to follow:

* **Sections** are the structure — a full-width band of the document with its own background, spacing and column layout.
* **Content** is what sits inside a section’s cells — text, images and buttons.

You edit the section as a whole through its settings, and the content inside it directly on the canvas.

## Working with sections

[Section titled “Working with sections”](#working-with-sections)

Sections stack top to bottom in the order the client will read them. You can add a section, reorder them, duplicate one, and delete one.

Each section is one of three [kinds](/en/proposals/sections/): a **default** section for free content, a **price** section for the structured pricing table, and an **accept** section for the signature block. The kind is chosen when the section is created and cannot be switched afterwards — a price section holds structured line items, and there is nothing sensible to turn those into if you convert it to free text.

## The toolbar

[Section titled “The toolbar”](#the-toolbar)

| Action                   | What it does                                                                                                      |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------- |
| **Preview**              | Renders the proposal the way the client will see it, without editing controls.                                    |
| **Library**              | Inserts a [reusable block](/en/library/blocks/) from your library.                                                |
| **Resolve placeholders** | Replaces the [placeholders](/en/proposals/placeholders/) in the document with the current customer’s real values. |
| **Generate PDF**         | Exports the proposal as a [PDF](/en/sending/pdf/).                                                                |
| **Versions**             | The [change history](/en/proposals/#change-history), with restore.                                                |
| **Analytics**            | How recipients have read the shared proposal. See [Proposal analytics](/en/proposals/analytics/).                 |
| **Edit details**         | Title, customer and template metadata, without leaving the editor.                                                |

**Undo** and **Redo** cover the last changes on the canvas.

## Saving

[Section titled “Saving”](#saving)

Changes are saved as you work, and each save adds an entry to the change history. Because a shared proposal is a [frozen snapshot](/en/proposals/#sharing-is-a-snapshot), saving does not change what a recipient currently sees — you have to share a new version for that.

# Images in a proposal

> Where images come from — uploads, external URLs and stock search — and where in a proposal they belong.

An [image block](/en/proposals/blocks/#image-imageblock) and a section [background](/en/proposals/sections/#background-background) both need a picture. There are three places one can come from.

## Where an image comes from

[Section titled “Where an image comes from”](#where-an-image-comes-from)

| Source                           | How you get it                                                                                                     |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| **An upload** (`assetId`)        | A file you put in your workspace. Crop and rotate happen in Pural, so you rarely prepare a file elsewhere first.   |
| **An external URL** (`imageUrl`) | Any absolute URL. Nothing is copied into your workspace — the recipient’s browser loads it from wherever it lives. |
| **A built-in background**        | The backgrounds Pural ships with, offered in the background picker.                                                |

The upload and the URL are exclusive: a block uses one or the other, never both.

An external URL is only as reliable as its host

Pural does not validate the host of an external URL, and it does not copy the file. If the URL is wrong, or the host takes the image down later, the proposal reaches your client with a broken image and nothing in the editor warns you. Look at the section in preview before sending.

## Stock photography

[Section titled “Stock photography”](#stock-photography)

An [AI assistant](/en/ai/authoring/) can search stock photography and place a result directly, which is the practical way to get a proposal illustrated without hunting for files yourself. It sees the actual pictures rather than filenames, so it can pick one that suits the section.

Two things worth knowing:

* The hourly search quota is shared across everyone in the workspace, so an assistant is told to search once per section and reuse what it found.
* Results that carry a stricter licence are filtered out before you ever see them.

If stock search is unavailable — no quota left, or not configured — an assistant is instructed to continue without an image rather than invent a URL.

## Where images belong

[Section titled “Where images belong”](#where-images-belong)

An image earns its place or it is decoration. A useful rule of thumb, and the one the guided prompt follows:

| Section                 | Images                                                   |
| ----------------------- | -------------------------------------------------------- |
| Cover                   | One, as a full-height background with a legibility layer |
| Team, testimonials      | One per person                                           |
| Features, benefits      | One per item                                             |
| Introduction, summary   | One or two                                               |
| Pricing, scope, closing | **None**                                                 |

A photo behind a full-height cover does more for a proposal than the same photo squeezed into a column. And a proposal that is nothing but text reads as a memo — the opposite failure is just as real.

## Images as a background

[Section titled “Images as a background”](#images-as-a-background)

A background image switches automatic contrast off, which is the one thing to remember about them. Text no longer adapts to what is behind it, so pair every background image with a legibility layer — `imageOpacity`, an overlay, or `contentFill`. See [Image backgrounds and legibility](/en/proposals/sections/#image-backgrounds-and-legibility-contentfill).

## Cropping surprises

[Section titled “Cropping surprises”](#cropping-surprises)

`objectFit: "cover"` with a fixed aspect ratio crops to fill. That is what you want for a row of images that should look even — and it is also how a portrait ends up cropped through someone’s head at `1:1`. A settings list cannot show you that. The preview can.

# Rows and columns

> Splitting a section into columns, setting relative column widths, and the limits that apply.

Inside a section, content sits in **rows**. A row is split into **cells**, and each cell holds its own stack of blocks. That is how you get a picture beside a paragraph instead of under it.

## Columns

[Section titled “Columns”](#columns)

A row can hold up to **four** cells. Beyond that a proposal column is too narrow to read on a phone, where every column collapses to full width anyway.

## Relative widths

[Section titled “Relative widths”](#relative-widths)

By default the cells in a row share the space equally. Widths let you weight them instead — they are ratios, not pixels or percentages:

| Widths      | Result                          |
| ----------- | ------------------------------- |
| `[1, 1]`    | Two equal columns               |
| `[1, 2]`    | A third and two thirds          |
| `[2, 1]`    | Two thirds and a third          |
| `[1, 1, 2]` | A quarter, a quarter and a half |

The list has to have exactly as many entries as the row has cells. A `[1, 2]` on a three-cell row does not partly apply — it is discarded, and the row renders as equal columns.

## Nesting

[Section titled “Nesting”](#nesting)

A cell can contain its own rows, one level deep. That covers the realistic case — a two-column split where one side is itself stacked — without letting a proposal turn into a grid nobody can maintain. Rows nested deeper than one level are dropped.

## On small screens

[Section titled “On small screens”](#on-small-screens)

Columns collapse to full width and stack in reading order: left to right, then top to bottom. Check a multi-column section in [preview](/en/proposals/editor/) before sending — a caption placed to the right of an image ends up underneath it on a phone, which is usually fine, but occasionally reads wrong.

# Placeholders

> Insert customer and company values that fill themselves in, instead of retyping them in every proposal.

A placeholder is a marker you drop into text that stands for a value Pural knows — the customer’s company, the contact’s name, your own organization details. It is what makes a [template](/en/library/templates/) reusable: write “Dear «contact name»” once and every proposal built from it addresses the right person.

## Inserting one

[Section titled “Inserting one”](#inserting-one)

In a [text block](/en/proposals/blocks/#text), start a placeholder from the editor’s insert menu and pick the value you want. It appears in the text as a single highlighted token, not as loose characters — you cannot accidentally break one by editing half of it.

## How they resolve

[Section titled “How they resolve”](#how-they-resolve)

Placeholders fill in from the **customer attached to the proposal**, plus the proposal itself and your organization. They are resolved every time the proposal is displayed — in the editor, on the public page, in the PDF — so attaching a different customer updates every placeholder at once. Nothing is stored as text and nothing has to be re-saved.

Where a value is missing — no customer attached yet, an empty field — the placeholder falls back to showing its own name in braces, `{{customer.name}}`. That is the signal that there is nothing to fill in from yet, not a broken placeholder.

**Resolve placeholders** in the editor toolbar switches between the two views: the real values, and the placeholder names. Use the first to read the proposal exactly as the client will, and the second to see at a glance which parts are placeholders at all.

## In a template, and in a proposal

[Section titled “In a template, and in a proposal”](#in-a-template-and-in-a-proposal)

The same placeholder means something different depending on where it sits:

* In a [template](/en/library/templates/) it is the whole point. There is no customer, so the template shows `{{customer.name}}` — that is the template being correct, not unfinished.
* In a proposal it should be filled. A placeholder still showing its braces in a proposal you are about to send means the value behind it is missing.

Typing a placeholder by hand does not work

Placeholders are editor objects, not text patterns. Typing something like `{{customer.name}}` into a paragraph produces exactly that string — Pural has no reason to treat it as special, and the client receives the braces verbatim. Always insert placeholders from the menu.

An [AI assistant](/en/ai/authoring/) over MCP *can* insert real placeholders, because it copies the exact markup from the workspace rather than typing the token. The check is the same either way: if you see braces in a proposal with a customer attached, look at whether that is a placeholder with a missing value or a piece of text somebody typed.

# Pricing and acceptance

> The price table and the acceptance block: the two sections that turn a document into an offer a client can say yes to.

Two section kinds exist because two parts of a proposal are not free text: what it costs, and how the client agrees to it.

## The price section

[Section titled “The price section”](#the-price-section)

A price section holds line items in a structured table rather than as typed-out text. Each line has its description, quantity and price, and the totals are calculated. That is the whole reason it is not a text block: a typed total goes stale the moment someone edits a line above it.

You can give the table a description — the framing sentence above the numbers — and there can be more than one price section in a proposal when you want to separate, say, one-off setup from a monthly fee.

### Optional and selectable items

[Section titled “Optional and selectable items”](#optional-and-selectable-items)

Line items can be offered as choices rather than as fixed scope, so the client picks what they want on the public page and the total updates with their selection. Quantities can be adjustable in the same way. Use this instead of sending three separate proposals for three package sizes.

## The accept section

[Section titled “The accept section”](#the-accept-section)

The accept section is what turns a document into an offer: it renders the acceptance controls on the [public page](/en/sending/public-page/), where the recipient can accept — signing by drawing a signature where that is configured — or decline.

Put it last. It is the end of the argument, and it reads as an interruption anywhere else.

Accepting sets the proposal to **Accepted** and declining to **Declined**, both visible in your proposal list without anyone having to email you about it.

# Sections

> The three section kinds and every setting that controls how a section looks: width, padding, rowGap, columnGap, minHeight, verticalAlign, background and contentFill.

A section is one full-width band of the proposal. It owns the background, the spacing and the column layout; the text, images and buttons live inside its cells.

## The three kinds

[Section titled “The three kinds”](#the-three-kinds)

| Kind        | What it is for                                                                                                                                       |
| ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Default** | Free content — text, images, buttons, in any column layout. Most sections are this.                                                                  |
| **Price**   | The structured pricing table. Line items, quantities and totals, calculated rather than typed. See [Pricing and acceptance](/en/proposals/pricing/). |
| **Accept**  | The signature and acceptance block the client uses to say yes. Usually the last section.                                                             |

The kind is fixed when the section is created. A price section stores structured line items and an accept section stores a signature configuration, and neither has a sensible free-text equivalent to convert into.

## Settings

[Section titled “Settings”](#settings)

Every setting below is optional, and leaving one out is not the same as it having no effect — it falls back to the default in the table. That matters when a single section looks subtly different from its neighbours: usually the setting was never set on that one section rather than deliberately changed.

### Width (`width`)

[Section titled “Width (width)”](#width-width)

How wide the content is allowed to grow, independent of the section’s own full-width background.

| Value | Result                              |
| ----- | ----------------------------------- |
| `s`   | Narrow — comfortable for long prose |
| `m`   | Medium                              |
| `l`   | Wide (default)                      |

### Padding (`padding`)

[Section titled “Padding (padding)”](#padding-padding)

The vertical and horizontal breathing room inside the section: `xs`, `s`, `m`, `lg` (default), `xl`, `2xl`. Larger values read as more deliberate and more expensive; they are also what makes a cover section feel like a cover.

### Row and column gaps (`rowGap`, `columnGap`)

[Section titled “Row and column gaps (rowGap, columnGap)”](#row-and-column-gaps-rowgap-columngap)

The space between stacked rows and between side-by-side columns: `xs`, `sm`, `md` (default), `lg`, `xl`. They are set separately, so you can keep columns tight while rows stay airy.

### Minimum height (`minHeight`)

[Section titled “Minimum height (minHeight)”](#minimum-height-minheight)

Forces the section to occupy at least part of the screen, regardless of how little content it holds: `none` (default), `1/3`, `1/2`, or `full` for a full-viewport section. This is how you build a cover that fills the screen.

### Vertical alignment (`verticalAlign`)

[Section titled “Vertical alignment (verticalAlign)”](#vertical-alignment-verticalalign)

Where the content sits when the section is taller than its content: `start` (default), `center` or `end`. It only has a visible effect together with a minimum height.

### Background (`background`)

[Section titled “Background (background)”](#background-background)

Either a solid colour, or an image with:

* **size** — `cover`, `contain` or `auto`
* **position** — `top`, `center` or `bottom`
* **image opacity**, plus an **overlay colour and opacity** for darkening a photo enough that text stays readable on top of it

### Automatic contrast

[Section titled “Automatic contrast”](#automatic-contrast)

Automatic contrast is not a setting you turn on. It always applies: Pural measures the luminance of the section background and picks the text colour itself, keeping the contrast at WCAG 4.5:1. That is why you can choose any background colour you like and the text stays readable.

There is no `autoContrast` setting and no way to switch it off — writing one has no effect.

Caution

Do not hard-code a text colour to compensate for a dark background. You end up fighting the contrast resolver, and the result can be text that is invisible on one background and fine on another.

The one exception is an **image background**, where automatic contrast does not apply — see below.

### Image backgrounds and legibility (`contentFill`)

[Section titled “Image backgrounds and legibility (contentFill)”](#image-backgrounds-and-legibility-contentfill)

A `type: "image"` background switches automatic contrast off. Nothing adapts the text to what is behind it, so a dark headline over a dark photo ships exactly as written, and the settings look perfectly correct while it does. Always pair an image background with a legibility layer.

Three of them, weakest to strongest:

| Setting                           | What it does                                    |
| --------------------------------- | ----------------------------------------------- |
| `imageOpacity`                    | Fades the image toward the section’s own colour |
| `overlayColor` + `overlayOpacity` | Lays a tint over the whole image                |
| `contentFill`                     | Puts a solid panel behind the content only      |

`contentFill` takes a colour, an opacity, a blur, a corner radius and an inset, so it can be anything from a barely-there frosted panel to a solid card. It is the reliable choice for a full-height cover with a headline on a busy photo.

An individual cell can carry its own `fill` with the same shape. It is suppressed when the section already sets `contentFill`, so the two never stack.

Tip

This is the case a settings report cannot judge for you. Look at the section in preview before sending it.

## Keep settings consistent

[Section titled “Keep settings consistent”](#keep-settings-consistent)

A proposal reads as one document when its sections agree. If every section uses `lg` padding and width `l` and one uses `m` and `s`, that section looks like a mistake even if nobody can say why. Vary the background deliberately — that is what separates a cover or a callout from body sections — and keep the structural settings the same unless you have a reason.

# Sending by email

> Connect your own Google or Microsoft mailbox and send the proposal from your address, not ours.

Pural sends proposals **from your own mailbox**. The client sees a mail from <you@yourcompany.com>, it lands in your Sent folder, and replies come back to you — none of which is true of a mail sent from a generic system address.

## Connect a mailbox

[Section titled “Connect a mailbox”](#connect-a-mailbox)

In **Settings → Email**, connect a **Google** or **Microsoft 365** account. You are taken to that provider’s own consent screen and back.

What Pural is allowed to do

The connection requests permission to **send** only. Pural never reads, modifies or deletes your existing mail, and a message is only ever sent when you explicitly send a proposal.

Connections show as **active** along with the connected address, and can be disconnected at any time. Disconnecting stops you sending from that address until you reconnect it; it does nothing to mail that has already gone out.

Connections expire, because the provider’s authorisation does. If one lapses, the send dialog tells you and links back to the settings page — reconnecting is the same flow as connecting.

## Sending

[Section titled “Sending”](#sending)

**Send Proposal** in the editor opens the send dialog:

* **Recipients** — pick from the customer’s [contacts](/en/customers/) or type an address. You can add several, and override the display name for one send when the contact record has it wrong.
* **Subject** — required.
* **Message** — optional, above the proposal link.
* **Language** — which email template language to use.

Sending marks the proposal **Sent** and, because the recipients are named, is what makes the [per-recipient analytics](/en/proposals/analytics/#per-recipient) possible.

## Email templates

[Section titled “Email templates”](#email-templates)

The mail body comes from an email template, so every proposal you send is worded consistently. Templates exist per language, and can use placeholders for the recipient and proposal details.

You can edit the text **for a single send** in the dialog — it is marked as edited, and **Revert** puts the template’s version back. Those edits stay with that one email and do not change the template.

## When you cannot send

[Section titled “When you cannot send”](#when-you-cannot-send)

Two cases the dialog will tell you about:

* **No email account connected** — connect one in Settings → Email.
* **No email template found** — create one, otherwise there is no body to send.

Sending is part of a paid plan. During an expired [trial](/en/settings/billing/) the option is unavailable until you upgrade — sharing a link still works.

# PDF export

> Turn a proposal into a PDF for attachments, archives and clients who want a file.

**Generate PDF** in the editor renders the proposal as a PDF: the same sections, the same branding, the same layout, in a file.

## What it is good for

[Section titled “What it is good for”](#what-it-is-good-for)

* A client whose procurement process needs a document
* Your own archive of what was offered, at the moment it was offered
* An attachment alongside the link

## What you lose

[Section titled “What you lose”](#what-you-lose)

A PDF is a snapshot of the content, so everything that makes the shared page a page stops working:

* No [analytics](/en/proposals/analytics/) — a file cannot report that it was read
* No accepting or declining — [acceptance](/en/proposals/pricing/#the-accept-section) happens on the public page
* No selectable pricing options — the PDF shows a fixed state, not a chooser

That is the argument for leading with the link and treating the PDF as the fallback: the link tells you what happened next, and the file does not.

## Layout

[Section titled “Layout”](#layout)

The PDF follows the proposal’s sections. Full-viewport minimum heights are a screen concept and do not translate to paper the way they do to a browser, so a cover section built around `full` height is worth checking in the export before you rely on it.

Recipients can also download the proposal as a PDF from the public page, and that download is counted as a click in analytics.

PDF export is part of a paid plan and is unavailable once a [trial](/en/settings/billing/) has ended.

# The client's view

> What the recipient sees when they open the link, and how accepting or declining works.

The share link opens a page, not a download. That page is the proposal — branded, laid out, readable on a phone — and it is where the client responds.

## What they see

[Section titled “What they see”](#what-they-see)

The proposal renders as you built it, with your logo, colours and fonts. Nothing about the editor is visible and no account is needed: the link itself is the access.

If the proposal has selectable or optional [pricing](/en/proposals/pricing/) items, the client picks what they want and the total updates as they choose.

They can also download the proposal as a [PDF](/en/sending/pdf/) from the page.

## Accepting and declining

[Section titled “Accepting and declining”](#accepting-and-declining)

Where the proposal has an [accept section](/en/proposals/pricing/#the-accept-section), the client can accept — signing by drawing a signature where that is configured — or decline.

The proposal’s status changes to **Accepted** or **Declined** immediately, so you find out from your proposal list rather than from an email you have to notice.

## What they see if things change

[Section titled “What they see if things change”](#what-they-see-if-things-change)

The link points at a [frozen version](/en/proposals/#sharing-is-a-snapshot), so edits you make afterwards do not appear until you share a new version. Two other states are worth knowing:

* **Back to editing** invalidates the link. A recipient returning to it no longer reaches the proposal.
* **Mark as expired** leaves the link resolving but shows an expired notice instead of the content.

Anyone with the link can open the proposal — that is what makes it easy to forward to a colleague who needs to see it, and the reason to treat the link as confidential.

# Plan and billing

> How the trial, seats and subscription work, and where to find invoices and payment details.

## The trial

[Section titled “The trial”](#the-trial)

New workspaces start on a trial, and a banner shows how many days are left.

When it ends, Pural keeps working for everything you have written: proposals, customers, templates and blocks stay accessible and editable. What stops is the outbound half — **sending proposals** and **exporting PDFs** — until you subscribe. Sharing a link continues to work.

Writes through an [AI client](/en/ai/connect/) also require an active subscription.

## Seats

[Section titled “Seats”](#seats)

The subscription is priced per seat, and a seat is a member of your organization. Inviting someone beyond your seat count prompts you to add one first; Pural tells you before the invitation goes out rather than after.

Seat changes are **prorated**, so adding someone mid-cycle costs the remainder of the cycle rather than a full period.

## Subscribing and managing

[Section titled “Subscribing and managing”](#subscribing-and-managing)

Subscribing takes you to a checkout, where you choose the number of seats and a monthly or yearly interval, and pay.

Afterwards, everything about the subscription lives in the billing portal, reached from the organization’s billing settings:

* Change the payment method
* Download invoices
* Change or cancel the subscription

## Who can do this

[Section titled “Who can do this”](#who-can-do-this)

Billing is an administrator’s job. Ordinary members see that a subscription exists but cannot change it — the billing page tells them so rather than failing silently when they try.

# Branding

> Colors, logo and spacing that every proposal inherits — set once, including automatically from your website.

Branding is set once per organization and applies to every proposal. It is what makes a proposal look like it came from your company rather than from a proposal tool.

## Prefill from your website

[Section titled “Prefill from your website”](#prefill-from-your-website)

Enter your website domain and choose **Analyze**. Pural reads the site and fills in your logo, brand colours and font — around 20 seconds.

Treat the result as a first draft: it is read from a live website, so it can pick a colour from a campaign banner rather than your actual brand palette. Everything it fills in stays editable, and if the scan fails or only partly succeeds you fill in the rest by hand. Nothing later depends on it having worked.

## What you can set

[Section titled “What you can set”](#what-you-can-set)

| Setting           | Effect                                                   |
| ----------------- | -------------------------------------------------------- |
| **Logo**          | Appears on proposals and on documents sent to customers  |
| **Brand colours** | The palette proposals draw from                          |
| **Font**          | The default typeface in proposals                        |
| **Background**    | The background of proposal pages                         |
| **Spacing**       | Default padding and row and column gaps for new sections |
| **Industry**      | Which templates Pural suggests                           |

## Branding and section settings

[Section titled “Branding and section settings”](#branding-and-section-settings)

Branding sets the defaults; a [section](/en/proposals/sections/) can still override spacing or use its own background where a cover or a callout needs one.

Changing branding affects proposals that have not been shared yet. A proposal already shared keeps showing the [version that was frozen](/en/proposals/#sharing-is-a-snapshot) at the time — so a rebrand does not silently restyle an offer a client is in the middle of reading. Share a new version if you want them to see it.

# Organization and team

> Your organization's name and address, inviting colleagues, and what each role is allowed to do.

Everything in Pural belongs to an **organization**: proposals, customers, templates, blocks, branding and billing. Inviting a colleague means giving them access to all of it.

## Organization details

[Section titled “Organization details”](#organization-details)

The organization has a **name** — the workspace name you set during onboarding — and a **slug**, a short URL-safe identifier. Both can be changed later.

## Inviting colleagues

[Section titled “Inviting colleagues”](#inviting-colleagues)

Invite by email address from the members list. The invitation is emailed as a link, and appears under **pending invitations** until it is used; you can cancel one that has not been accepted yet.

An invited person joining an existing organization skips the onboarding wizard — the workspace is already set up, and they should not be asked to name it again.

Invitations are tied to your plan’s seat count. If an invitation would exceed it, Pural tells you before sending and offers to add seats — see [Plan and billing](/en/settings/billing/).

## Roles

[Section titled “Roles”](#roles)

Members are either **admins** or ordinary **members**. Administrators manage the organization itself: members and their roles, branding, and billing. Members work on proposals, customers, templates and blocks.

You can promote a member to admin and demote an admin to member from the members list, and remove a member entirely.

Access is expressed as fine-grained capabilities underneath — which is what lets, for example, an [MCP connection](/en/ai/connect/) hold strictly fewer permissions than the person who created it.

## Multiple organizations

[Section titled “Multiple organizations”](#multiple-organizations)

One account can belong to several organizations — an agency working under two brands, a consultant with their own workspace plus a client’s. Everything is scoped to the one you are currently in, so check which that is before wondering where a proposal went.