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 (it sits just below Contacts; you may remember it tucked under Contacts, or as Contact fields). 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 you define shows up on every contact's edit form, but only once that contact actually has a value for it. An empty field stays hidden, so adding a "Forklift licence expiry" field doesn't clutter the record of every florist and photographer who will never have one. Records stay as clean as they were before you added the field.

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 an enquiry 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, and the most recently uploaded of the two is the one shown. 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.

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: a text box for Text, a date picker for Date, a number box for Number, and a time picker for Time. A Choice field shows its current value collapsed, with an Edit reveal so the full option list only appears 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.

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:

Map a request to any value-storing field (Text, Choice, Date, Number, or Time) 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.
Map a document request to an Upload field, and the most recent file they submit becomes the latest document on that field.

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.

Because empty fields stay hidden on a contact, you can afford to define a field that only applies to a slice of your address book without it cluttering everyone else. The field only surfaces on the contacts that actually have 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 points at it) you can delete it outright. If it is in use, deleting it would throw away data you have already collected, so 1pm keeps the field and tells you what is blocking the delete (a value on a contact, or a request mapped to 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. 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.