Cover Pages are defined as a YAML document that describes the sections and fields of your agreement. Common Paper renders that definition as a fillable form, a web agreement, a PDF, and a Word export. This article covers every key and input type available to you.
If you're new to Custom Agreements, start with Cover Pages for how to get to the form builder in the first place.
The basic shape
A definition has a title and a list of sections. Each section groups related fields.
title: Consulting Agreement
sections:
- heading: Services
fields:
services_description:
label: Description of services
input: textarea
- heading: Payment
fields:
payment_terms:
label: Payment terms
input: text
default: Net 30
Field keys, like services_description, are internal identifiers. They must start with a lowercase letter and contain only lowercase letters, numbers, and underscores. Each key must be unique across the whole template.
Every section needs at least one field, unless it is a header or an import section.
Top-level settings
All of these are optional except title.
Key | What it does |
| The display name of the agreement, shown as the heading on the agreement, PDF, and Word export. Required. |
| Renames the "Cover Page" heading. Use this when your agreement calls its terms something else, like Key Terms, Order Form, or Statement of Work. |
| Smaller text under the terms label, shown on the PDF and Word export. |
| Explanatory text shown in a highlighted box above the Cover Page, like the framework explanation on our standard agreements. |
| A heading row rendered at the top of the terms table, such as "Key Terms". |
| Smaller text under the terms heading, such as "The key legal terms of this Agreement are as follows:". |
| The sentence above the signature blocks. Defaults to "By signing this Cover Page, each party agrees to enter into the Agreement." |
| Renames the two parties. Takes |
| The footer on PDF and Word exports. Write |
title: Independent Contractor Agreement
terms_label: Framework Terms
info_box: The Framework Terms have 2 parts...
signing_disclaimer: By signing below, both parties accept these Framework Terms.
parties:
sender: Company
recipient: Contractor
sections:
...
Sections
Each entry in sections: is one row of the Cover Page, with the heading on the left and its fields on the right.
Key | What it does |
| The section name shown on the left. |
| Smaller text under the heading. |
| The section always appears on the agreement and cannot be excluded by the sender. |
| The section is excluded by default. Senders can include it per agreement with a checkbox when creating the agreement. |
| Makes the section a full-width header row instead of a fields row. Use it to divide the Cover Page, for example "Additions and Modifications". A header section has no fields. |
| Pulls in a ready-made section. See Imports below. |
| Who can edit the section's fields. See Access levels below. |
sections:
- heading: Optional rider
subheading: Only applies to enterprise deals
included: false
fields:
rider_details:
label: Rider details
input: textarea
- header: Additions and Modifications
Fields
Fields live in a fields: mapping inside a section. The mapping key is the field key, and everything else is configuration.
Key | What it does |
| The name shown above the input and next to the value on the agreement. |
| The input type. See Input types below. Required. |
| Guidance shown only on the form while filling it in. It does not appear on the finished agreement. |
| Placeholder text inside the empty input. |
| The field always appears on the agreement, and a value must be entered before the agreement can be sent. |
| Prefills the field. Senders can change it when creating an agreement. |
| The choices for |
| The currency code for |
| Who can edit the field. Overrides the section's |
Fields without a value are left off the finished agreement, unless they are required or fixed.
Input types
Input | Renders as |
| Single-line text box |
| Multi-line text box |
| Multi-line text box with formatting (bold, lists, links) preserved on the agreement |
| Number input |
| Money input with a currency symbol. Set |
| A money amount plus a per-unit select, shown on one line like "$500.00 per hour". |
| Date picker |
| Email input |
| One choice from |
| One choice from |
| Multiple choices from |
| Dropdown of US states |
| A full address block. Its parts are |
| Pick a PDF from your organization's attachment library, or upload a new one. The file is referenced on the agreement and appended to the PDF. |
| Uneditable text set by |
Two input types take a mapping for their default rather than a single value. Use only the component names listed above as keys, and for rate, a per default has to be one of the field's own options.
fee:
label: Rate
input: rate
options:
- hour
- day
default:
amount: 500
per: hour
contractor_address:
label: Contractor address
input: address
default:
country: USA
street_address: 100 Main Street
city: New York
state: New York
zip: "10001"
NOTE: address and rate fields expand into one key per component, such as contractor_address_city. Those expanded keys share the same namespace as your regular field keys, so a separate field named contractor_address_city would collide and be rejected.
Access levels
By default only organization admins can edit field values when creating an agreement. Add access to a field or a whole section to open it up.
Value | Who can edit |
| Organization admins only. This is the default. |
| Standard members and admins. |
| The agreement recipient, plus standard members and admins. |
A field-level access overrides its section's. Locked fields show read-only on the form and keep their template defaults.
Recipients are a special case. While negotiation is enabled they can propose changes to any field as before. When negotiation is disabled, access: recipient fields appear as inputs on the recipient's view of the agreement so they can fill them in before signing. Marking one of these fields required: true means the recipient must fill it in before signing. It does not block the sender from sending.
NOTE: attachment fields are the one exception. Recipients can never edit or propose changes to them, because doing so would expose your organization's attachment library. Setting access: recipient on an attachment field has no effect.
sections:
- heading: Fees
access: standard
fields:
fee:
label: Monthly fee
input: currency
po_number:
label: PO number
input: text
access: recipient
Imports
Imports drop in a ready-made section with one line. You can use each import only once per template. Today there is one import available:
sections:
- import: governing_law
This renders a Governing Law & Chosen Courts section backed by the same pickers our standard agreements use. To preset answers, add a defaults: mapping. To limit the pickers to specific jurisdictions, add options:.
sections:
- import: governing_law
options:
- New York
- Delaware
- California
defaults:
governing_law_region: Delaware
chosen_courts_region: Delaware
The pickers list US states. Organizations allowed to use additional courts also get the same international jurisdictions available on standard agreements, such as England and Wales.
You can also fill the import's inputs in the form preview and switch back to the YAML tab, and the defaults will be written into the YAML for you.
The editor
The template editor has two tabs. The YAML tab is the source of truth. The Form view tab renders your template as the fill-in form a sender will see.
Values you enter in Form view are written back into the YAML as default: values when you switch back. This is a quick way to set defaults without typing YAML, including the mapping syntax for rate and address fields.
Supported input types and import names highlight in the editor as you type, so a typo like input: dropdown stays plain while input: select lights up.
A definition is capped at 100,000 bytes. Keys the form builder doesn't recognize are ignored rather than rejected, so a misspelled key produces no error and no effect. If something you added isn't showing up, check the spelling against the tables above.
Versions
Every save creates a new version and makes it current immediately. The version dropdown on the edit page lets you load any previous version, and saving while an old version is loaded makes that content the newest version.
Agreements pin the version they were created from, so they always render exactly what the signer saw.
