Deal properties

A deal comes with the fields everyone needs: a name, an amount, a close date, a stage. Deal properties are the fields *you* need: the ones particular to how you run jobs. Consent lodged? Which architect? What was the client's opening budget? Where's the signed variation?

You build the list once in settings, and it shows up on every deal.

Building your list

Go to Settings → Deals & pipeline and open the Deal properties tab. (You need to be an owner.)

Click Add a deal property and fill in:

• Field name: what you want it called. "Consent lodged", "Architect", "Client's opening budget".
• Type of input: how it's filled in on a deal:

| Type | What you get on the deal | |---|---| | Single-line text | A plain box | | Multi-line text | A bigger box for notes | | Number | A number box | | Date | A date picker | | Checkbox (yes/no) | A tick box | | Dropdown | A list you choose from: you set the options | | Link | A web address, shown as a clickable link | | File upload | Attach a PDF, photo or document | | Yes / No / N-A (with explanation) | Three buttons plus a box for the detail: see the sectioned Details form | | File uploads (several) | Several documents on one field: see the sectioned Details form |

• Dropdown options (dropdowns only): the choices, comma-separated: Kitchen, Bathroom, Full house.
• Default value (optional): what the field starts as.
• Hint (optional): a line of guidance under the field for whoever fills it in.
• Section (optional): a heading to group this field under. Sections you've already used show up as buttons above the box, so you can see what's there and pick one instead of retyping it; type a new name to start another. It only changes what you see if you use the sectioned Details form.
• Add to new deals by default: tick this and every deal created from now on starts with the field already on it, filled in with the default value.

Putting them in order

The settings list is grouped under the same headings the deal shows, and you arrange it right there: no export, no editing a file, no import.

• A field: grab the ⠿ handle beside it and drag it up or down within its heading. The ↑ and ↓ buttons next to Edit do the same thing, and work on a keyboard.
• A whole section: grab the ⠿ handle in the section's heading bar and drag the block above or below another one. Everything inside it comes along in the order you left it. Again, ↑ and ↓ in the heading bar do the same.
• A field into a different heading: drag it onto a field under the heading you want, and it lands in that spot with its heading changed. Dropping it on a field in the Other group takes its heading off altogether.

Each move saves on its own. There's no Save button to remember, and if a save is refused the list goes straight back to where it was (heading and all) with the reason shown.

A few things it deliberately won't do:

• You can't drag a field into a heading that doesn't exist yet. Drops land on a field, and a heading with nothing under it isn't on the page. Set the Section in the field editor for the first one: that way a typo suggests the heading you meant rather than quietly creating a new one. The ↑ and ↓ buttons stay inside a heading too, so a keyboard nudge never re-files a field by accident; the field editor is the way to change a heading without a mouse.
• The Other group stays at the bottom. It's the "everything not sectioned yet" group, so it's always last. The fields inside it still reorder normally.
• If someone else has added, archived or restored a field since your page loaded, the move is refused and you're asked to reload, better than shuffling a list that no longer matches what's there.
• Same if someone else has reordered the list while you had it open. Your move goes back where it was and you're asked to reload, so two people rearranging at once can't quietly wipe out each other's work.

Restoring an archived field puts it at the end of the list, not back in its old spot: rearranging the fields that are live renumbers them, so the place it used to hold belongs to something else by then. Drag it back where you want it.

Two things worth knowing

You can rename a field, and a type can widen. The name is yours to change whenever: it's only a label. The *type* only ever changes in a direction that keeps every answer already saved, so Edit offers you exactly the types this field can still become:

• Single-line text → Multi-line text, whenever you like. Nothing can be lost; the box just gets bigger.
• Single-line text, Multi-line text, Checkbox or Dropdown → Yes / No / N-A, as long as every answer already saved on a deal is Yes, No or N/A. If anything else is stored, the change is refused and the message names the values in the way, so you can clear them and try again. (A stray space counts: " Yes " isn't the same answer to a Yes/No/N-A field.)

Anything else (narrowing Multi-line text back to Single-line, turning a Yes/No/N-A field back into a checkbox, or swapping to an unrelated type) is refused, because deals already hold values in the old shape. Archive the old field and add a new one.

Check your automations before widening to Yes / No / N-A. Nothing stops you, but an automation step that sets that field to anything other than Yes, No or N/A (a date, a note, a number) starts failing its run from the moment the type changes. Open Automations and fix those steps in the same sitting.

A field a lead capture form fills can't become Yes / No / N-A while the form still asks for it: a lead form has no Yes/No/N-A question, so every answer it collected would arrive in a shape the field couldn't keep. The message names the form; point that question at another field first.

Both of these work the same way in Import, so a catalogue you exported, edited and re-imported widens the fields it names instead of failing the whole document.

The settings list shows your names, not the internal key. Automations and exports still need a fixed key that never changes: hover a field's name to see it, or open Edit, which spells it out under Field name.

Archiving is safe, and reversible. Archive a field and it disappears from the settings list and stops being offered, but every value already saved on a deal stays put, and any automation using it keeps working. Nothing is deleted. It moves to an Archived list at the bottom of the panel with a Restore button; the field name stays reserved while it's there, so a new field can't quietly take it over.

Clearing out a long list in one go (after a HubSpot import, say) is quicker with Select all unsectioned and Archive selected; the rollout walkthrough covers the order to do it in.

An archived field also keeps checking its own type. If you archive a number field, nothing can start writing "soon" into it behind your back, so restoring it later never surfaces a value the deal page then refuses to save.

Removing a dropdown option doesn't strand a deal. A deal already holding the retired option keeps showing it, and you can still edit and save everything else on that deal. Pick a new value when you're ready, but you'll never be forced to just to fix an unrelated field.

Filling them in

Open a native deal and choose Overview → Details. Your defined fields render at the top, in order, as the input type you chose. Below them sit any other properties on that deal (ones an automation wrote, or ones from before you built your list) as plain name/value rows you can still edit.

Hit Save and you're done.

Search by name or value to find a field quickly. Remove clears its value from this deal when you save; the shared field definition stays available. HubSpot-linked deals use the same tab for their mirrored properties, with editing and removal available for fields your organisation has enabled.

Using them in automations

This is where the list earns its keep. In Settings → Client experience → Automations, the Check a deal property step (it used to be called "Dependent property") reads your fields directly:

• The property dropdown lists your fields under *your* names, not internal keys.
• The step then asks the question your field's type allows, with nothing to retype:

- Dropdown → tick-boxes of its exact options. - Checkbox (yes/no) → a Yes and a No tick-box. - Date → a comparison: *is on*, *is before*, *is after*, *is within the next N days*, or *is more than N days ago*, with a date picker or a number of days. So "site start is within the next 14 days" is now something you can actually ask. - Number → *equals*, *is greater than*, *is less than* or *is between*, with number boxes. - Text and anything without a defined type → the comma-separated list, same as always.

So: "if Job type is Kitchen → send the kitchen pack; otherwise → send the general pack" is now three clicks and nothing to mistype.

The same controls appear in two more places:

• The "Deal property is set to…" trigger: the values that fire the automation are picked the same way, so a trigger can't sit there waiting for a value nobody will ever type exactly. For a date or a number the trigger keeps its *any of* list: each value gets its own picker, with a Remove beside it and a blank one underneath to add the next.
• The "Set a property" step: it now picks the property from the same list, and the value box matches the field's type. It also *checks* what it writes: if a step would put something in a field that the deal page would refuse (a date that isn't a date, an option that isn't on the list), the write is refused instead of quietly saving a value you can't edit afterwards. The whole automation stops there, not just that one step: the follow-up email and the task after it don't run either. The run shows the reason, and fixing the value on the step lets the next enrolment through.
• The "Create a deal" step: the properties it copies across from the enrolled contact get the same check, at the moment the deal is made. A copied answer the new deal's Details tab would refuse (free text landing in a date field, say) stops the step rather than creating a deal nobody can save until they retype the field by hand. A file field can't be filled this way at all: the file has to be uploaded to a deal, and the deal doesn't exist yet.

Website lead forms behave differently, on purpose. A visitor filling in your form is not an author you can send back to fix a step. If one of their answers lands in a property that refuses it, the lead is still created and every answer is still written out in full in the submission note on the deal, only that one field is left unset, so the Details tab still saves. The note ends with a "Not stored on the Details tab" list naming each such answer and the reason it wasn't kept, so nothing is lost quietly. You lose nothing except a pre-filled box.

Automations you already built route exactly as they did; nothing needed re-saving. The one behaviour that changes for an existing automation is that check above: a "Set a property" step that has been writing a value the deal page would refuse used to appear to succeed, and now stops the run instead. If you open such a step, the value is still there in a plain text box with a note saying why it will be refused. The same is true on the deal card itself: a property whose stored value isn't a real date or a real number opens in a plain text box showing what is actually there, rather than an empty box that reads as "nothing set" over a value that is very much set.

Filling them from your website form

A question on a website lead form can be pointed straight at one of these fields, under Where it's saved in the form editor. The answer then lands in that field on every deal the form creates, and the field's row in this panel says so: Filled by: <form name> · <question>. A field nothing fills has no such line, which is the quickest way to spot a property you set up and then never wired to anything.

Archived fields carry the line too. If you archive a field a live form still writes to, that is the row telling you why its name is still taken and why adding a new field under the same name is refused.

It works the other way round too. A form question left on Custom column gets a deal property of its own the first time the form is saved, named after the question. That is why a field you never created by hand may already be listed here: your form made it, so what it collects has a name instead of sitting unlabelled at the bottom of the Details tab. See the lead-capture doc for the whole picture.

Files

A file-upload field takes one file at a time: attach it, and the deal shows a link to open it. Replacing it uploads a new one; Clear removes it from the field without destroying the uploaded copy. Files are encrypted at rest and only your staff can open them (customers never see deal properties).

Limit is 20 MB per file.

A file field can only ever hold a file uploaded to *that* deal, under *that* field. An automation cannot point one deal's file field at another deal's attachment. A Set property step that tries fails the step and writes nothing, rather than showing you someone else's document.