Custom contact fields — Help

Every contact carries a few things that 1pm asks for out of the box: a name, a business, a role, an email, a phone number. But the things you actually need to track on a supplier are often more specific than that. A licence number. An account code. Whether their public liability cover is still in date. A T-shirt size for the volunteer crew. Custom contact fields let you add those to every contact, so the detail you care about lives on the person rather than in a spreadsheet you have to dig out each time.

The real payoff is that a custom field can be filled in by the crew member themselves. Tie a request to a field, and when the supplier answers it (or uploads the document), their reply lands straight on their contact record and stays there for the next event. This article covers defining your own fields, the field types on offer, and how to collect them automatically.

Where to find it

Open Fields from the sidebar. Custom fields apply to every contact in your address book, not to one person or one event, so they live here rather than on an individual contact.

A field that saves to the contact shows on every contact's Details tab, below the standard fields, whether or not that contact has a value yet. An empty field shows with its own input so you can fill it in there and then. Empty single-line Text fields are the exception: they sit in the Add field value list at the bottom instead, so a long list of rarely used text fields doesn't stretch every record. A field ticked Don't save answers to the contact profile never appears on a contact at all (see "Good uses, and keeping it tidy" below).

The field types

When you add a field you pick its type, and the type is fixed once the field exists, so pick it deliberately. A Choice field's options are not locked the same way: you can edit, add, or remove them later, and 1pm carries existing selections across when you do.

Text. A free-text value. Keep it to a single line for a licence number, an account code, or an arrival preference, or switch it to multi-line when you need room for a longer note or a standing briefing.
Choice. A fixed set of options you define, picked from a list. Set one option per line, with at least two. Tick "Allow more than one selection" if a contact can have several at once (dietary tags, for instance); leave it unticked for a single pick (a shirt size, a tier). A contact's selection is stored as the chosen option or options.
Date. A calendar value entered through a date picker. Use it for a certificate expiry, an induction date, or any fixed day you want to keep against the contact. It is stored as a plain date and is not wired into document expiry reminders, so treat it as a record of the date rather than an alarm. One special case: on a lead form that hides the standard fields, a Date field also seeds the event date when you convert the lead, so 1pm can still fill the booking's date from your own field (the form editor marks which one it will use).
Number. A numeric value such as a party size, a table count, or a vehicle count. Number fields also roll up: on an event's planner page, 1pm totals the value across all the event's contacts (the combined party size, say), which stays on the planner view and never appears on a crew's run of show.
Time. A clock time, stored tidily as HH:mm. Use it for a standing call time or a recurring slot a supplier keeps.
Upload. Holds the current document for this contact: a public liability certificate, an ID, a permit. The file can arrive either way, from a crew member submitting against a request mapped to the field, or from you attaching it yourself. The one shown is the most recent file you have not rejected, so rejecting a bad upload puts the previously approved document back on the record rather than leaving the contact looking unequipped. Everything else the contact has sent for that field is still there under History, across every event. Tick "Require an expiry date" when you define the field and whoever attaches the document has to say when it runs out, which is what makes it trackable rather than merely filed. See tracking one document across every event for the whole picture.

Adding and ordering fields

Give the field a name (for example "Public liability certificate"), choose the type, and for a Choice field type the options into the box. Add field saves it, and the form clears so you can add several in a row.

The list of fields can be reordered: grab the drag handle on any field and drop it where you want. The order you set here is the order the fields appear in everywhere they show, so put the things you look at most near the top.

Filling fields in yourself

You can set any field's value directly on the contact. Open the contact, and the custom fields sit beneath the standard ones on the Details tab: a text box for Text, a date picker for Date, a number box for Number, and a time picker for Time. A field that already has a value shows it with Edit and Clear buttons, so the inputs only appear when you want to change it. This is the right path when you already know the value, or a supplier told you over the phone.

A value the contact entered themselves, from a request on their link, carries a note such as "Updated by Tony's AV 3 Mar 27", so you can tell their answer from one you typed. The history button beside a field lists every value it has held and where each one came from.

Upload fields work the same way: you can attach the document yourself rather than waiting for a submission, which is the usual fix when a supplier emails you the certificate instead of using their link. If the field requires an expiry date, you have to enter it as you attach the file, exactly as a crew member would.

Letting crew fill fields in for you

This is where custom fields earn their keep. Instead of typing every supplier's licence number yourself, you can ask them once and have their answer write straight onto their record.

When you create a request (these are asked of the crew on an event, and you can narrow a question to a named subset with a conditional section), you can point it at a custom field instead of asking a loose question:

Pick Fields as the request kind and choose a Text, Choice, Date, Number, or Time field under Custom or linked field. Fields that write to the contact are listed under + Save to contact, and the crew member's answer writes through to that field on their contact. The request card on their share link shows the right input: a text box for Text, radio buttons or checkboxes for Choice, a date picker for Date, a number box for Number, a time picker for Time.
On an Upload request, choose the field under Save latest file to, and the most recent file they submit becomes the latest document on that field.
In a request pack, use the Contact field kind for a value, or Also save their file to a contact field on an Upload ask.

A new answer replaces the value already on the contact, whether you typed it or the contact did.

Because the value lands on the contact and not just on the event, the next time you book that supplier the licence number or the certificate is already there. You only have to ask once. So you can ask your entire casual pool for their shirt size in one go, or use a named-crew conditional section to collect a licence number from just one contractor.

Good uses, and keeping it tidy

Custom fields are at their best for details that are durable and that you reuse: things that belong to the person and outlast any single event. A licence or insurance document, a supplier account code, a uniform size, a standing dietary requirement. For one-off, event-specific questions ("what time will you arrive on Saturday?") a plain request without a field mapping is usually the better fit, since you don't want a one-night answer permanently stamped on the contact.

There's a middle option too. When you define a field you can tick "Don't save answers to the contact profile", and each answer stays on its own request instead of writing through to the record. That's how you reuse a set of Choice options across events without stamping everyone's contact with an answer that expires the moment the job ends.

The test is simple: would you want to read this next year, about this person, in a different context? If yes, let it save to the contact. If not, keep it on the request.

A field that saves to the contact shows on every contact, including the ones it will never apply to, so be sparing with fields that only suit a slice of your address book. A single-line Text field is the lightest choice for those, since it stays in the Add field value list until a contact has a value.

Removing a field you no longer need

There are two ways to retire a field, and 1pm steers you to the safe one. If a field has never been used (no contact holds a value for it, and no request, request pack or lead form points at it) you can delete it outright. If it is in use, deleting it would throw away data you have already collected or leave an ask pointing at nothing, so 1pm keeps the field and tells you what is blocking the delete (a value on a contact, or a request, request pack or lead form that uses it). In that case archive it instead: archiving takes the field off your active list and hides it from new records without erasing what crew already submitted. A request that points at an archived field stops counting as required: crew can no longer answer it, so it no longer holds anyone back from finishing their requests or triggers reminders. Reach for delete only to tidy up a field you created by mistake, and archive for anything that has done real work.

Asking crew for documents and info covers building a request in full.
Asking everyone for the same thing covers asking every crew member on an event the same question.
A contact's request history shows everything a contact has ever sent back, including the values that wrote through to their custom fields.
Tracking one document across every event covers linking your requests to an Upload field so a supplier's insurance reads as one history rather than a file per event.