1pm
Start free trial
← All help articles

Portals

eventscrewgetting-startedfiles-and-uploads
Portals

A Portal is a stripped-back kind of record built for one job: gathering documents and information from a group of people when there is no event to attach it to. It has no run of show, no venue, no dates, no value, and no pax. What it keeps is the useful half of an event: a crew list, a self-registration link, and the Requests checklist each person works through on their own no-login link. If you have ever wanted to run onboarding, an application process, or a waiver round in 1pm without inventing a fake event to hold it, a Portal is that container, purpose-built.

What a Portal is for

The shape fits anything where you need the same set of documents or answers from a number of people, on a rolling basis, with no single date driving it:

  • Contractor and supplier onboarding. Public liability certificates, signed agreements, licences, induction acknowledgements, one per contractor, tracked and chased as they expire.
  • Staff and crew onboarding. Bank details, emergency contacts, a signed contract, a policy acknowledgement.
  • Applications and expressions of interest. Stallholders for a market, vendors for a fair, performers for a lineup, each submitting their details and paperwork through one link.
  • Waivers and agreements. A second-shooter agreement, a volunteer waiver, a model release, signed once and filed.

In every case the people are stored as crew (a crew member in 1pm is a contact you have given a share link to), and the Requests you build are their checklist. Everything an event carries and a Portal does not, the timeline, the BEO, pax and covers, quotes and payments, simply is not there to distract you.

How a Portal differs from an event

A Portal is deliberately narrow. When you open one, the editor hides everything that belongs to a booking: the date and time, the status, pax, the event value, the Space, the zone, the program link, the physical location, and the BEO tab. You give it a name and nothing else is required.

It also stays out of the way of your real events. Portals do not appear in your events list, they are excluded from reports and the calendar feed, they never take part in Space double-booking checks or automations, and they do not count toward your events allowance. A Portal is a side channel for paperwork, not part of your event-of-record.

Creating a Portal

Portals live under the Events area, on their own tab in the strip along the top: Events / Portals / Templates. Open the Portals tab and choose New Portal. Give it a name that reads as what it is ("Contractor register", "2026 stallholder applications", "Second-shooter agreements") and save. That is the whole setup. There are no dates to pick and no fields to configure before you can start.

The tab shows a running count of your Portals, and each row is a Portal rather than an event, so your bookings and your onboarding never mix on the same list.

Getting people in

There are two ways to bring people into a Portal, and you can use both at once.

  • Add them yourself. Add each person to the Portal as a crew member, exactly as you would add crew to an event. Best when you already know who they are.
  • Let them register themselves. Turn on self-registration and publish the one link. Anyone who opens it enters their name and email and is issued their own private link straight away. Best for an open-ended or unknown group: a market you are taking applications for, a contractor pool you are still building. See Letting crew and guests register themselves.

Either way, each person ends up with a shareable live link that needs no account and no password. They open it on their phone, see their Requests card, and work down it.

The Requests checklist

Requests are the heart of a Portal. Open the Portal, expand the Requests panel, and build the checklist once. Every person on the Portal sees it on their own link and completes it independently. The request types cover the usual onboarding needs:

  • Upload for documents, with an optional expiry date the person enters alongside the file, which is what turns a Portal into a live compliance tracker rather than a folder of files.
  • Text for details you need in writing.
  • Choice for confirmations and selections, where a single-option Choice becomes an acknowledgement tick.
  • Contact field to write an answer straight back onto the person's contact record.
  • Terms / Agreement to present your terms and capture a recorded, version-pinned acceptance, with an optional typed name or drawn signature. See Getting people to accept and sign your terms.

If different people need different documents, wrap the role-specific requests in a Section limited to the named crew it applies to, so everyone else never sees it. The full detail on request types, sections, and reference documents is in Asking crew for documents and info and Asking everyone for the same thing.

As documents arrive you approve or reject each one in place, and the Requests dashboard on the Portal turns the whole group into a scoreboard: who is cleared, who is outstanding, whose certificate is about to lapse. See Reviewing crew uploads and The Requests dashboard.

Closing and reopening a Portal

When an intake is finished, you do not have to delete the Portal or unpick its links one by one. Open the Portal and use the Close portal control. Closing turns off both public entry points at once: no new self-registrations come in, and every existing link shows a closed message when opened. Your submitted documents are untouched, and your own access as the planner is unaffected, so you can still review, approve, and export everything that came in.

Reopening is a single click and turns both back on. Close a Portal at the end of a season and reopen it when the next round starts, or close it for good once you have what you need.

Portals and the onboarding workflow

If your interest in 1pm is onboarding and document compliance rather than event management, a Portal is the container the workflow was crying out for. The full end-to-end setup, from an embedded registration form on your website through to a cross-account view of everything expiring soon, is written up in Using 1pm for onboarding and compliance requests. That article predates Portals and describes using an ordinary event record as the container, telling you to ignore the date-driven parts. With a Portal there is nothing to ignore: the parts that did not apply are simply gone. Read it for the workflow, and use a Portal as the record it all hangs off.

Related articles