Portals — Help

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 an onboarding portal differs from an event

Underneath, an onboarding portal and an event are the same kind of record, which is why they behave alike wherever you share a link or ask somebody for something. What differs is what each is for.

The app says onboarding portal for the dateless kind and your own word (event, unless you have renamed it) for a booking, and where a screen covers both it names both: a filter reading "Events only" or "Onboarding portals only" is telling you exactly which it means. Portals in the sidebar means the onboarding kind only. Two other things in 1pm are also called portals and are neither of these: a client's booking portal, where they accept the quote and pay, and the event portal, the live page crew and clients open on their link. Both are covered in your booking portal and your event portal.

An onboarding 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 bookings. Onboarding portals do not appear in your events list, they never reach the calendar feed, and they never take part in Space double-booking checks. They are left out of every report that counts dates, Spaces or money, since a portal has none of those.

They do appear on the reports that count what you have asked people for. Outstanding requests, Response speed, Request answers and Expiring documents, all under Requests in Reports, cover your events and your onboarding portals together, with a filter to look at one kind at a time. Portals, under Operations, lists the onboarding portals on their own.

Automations are a half-and-half case, so it is worth being precise. The date-driven ones skip portals entirely: every scheduled job that counts days to or from an event date is filtered to real events, which is what you want given a portal's date is only a placeholder. The trigger-driven ones do fire, exactly as they would on an event, because nothing in the dispatch looks at what kind of record it is. Someone self-registering on a portal, finishing their requests, or having an upload rejected all run your automations as normal, which is the half you are usually relying on for onboarding anyway.

One thing they do share: an open onboarding portal counts as active on your plan, the same way a live booking does, until you close it. Closing an intake you have finished with is what takes it back off the meter. See Your crew allowance and account usage.

Creating a portal

Portals has its own row in the sidebar. Open it 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.

Each row on that list is a portal rather than a booking, so your events 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. The links are not revoked by closing, only switched off, so reopening brings the same links back to life and nobody has to be re-invited. 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.

One thing to know before you go looking for a Portal you closed months ago: closed Portals are hidden from the Portals list by default. The "Show closed portals" checkbox above the list is what brings them back, and without it a closed Portal looks deleted.

Closing, not deleting, is the finished-with-it action. Delete is at the foot of the Options tab inside a Portal's settings, and it is permanent: it destroys every document uploaded to the Portal along with the expiry dates and approval history recorded against them, and none of it can be recovered. The confirmation counts the files for you rather than asking a vague "are you sure", and on a Portal it points you at closing instead. Keep Delete for a Portal you created by mistake.

Converting between the two

A record does not have to stay the kind it started as. Open it, and at the foot of its settings you will find Convert to onboarding portal, or Convert to {event} portal on one that is already an onboarding portal. It works in both directions and it deletes nothing, so the cost of getting it wrong is one click back.

This is useful more often than it sounds. A lead that turns out to be a contractor intake rather than a booking. An onboarding portal you set up for a supplier round that has now grown a date, a venue and an invoice.

Converting an event to an onboarding portal. Nothing is deleted, but the parts an onboarding portal has no use for stop showing, and the confirmation tells you exactly what those are for this particular record, with real counts. Timeline items stay saved but the run of show is hidden. Quotes, invoices and confirmations stay saved but the Pricing tab and their client links go out of reach. Any sent and paid invoicing drops out of your revenue, pipeline and Space reports, and the confirmation names the figure so there is no surprise. It leaves the calendar, and stops holding its Space. Converting back restores all of it.

Converting an onboarding portal to an event. Everyone in the portal comes with it, along with their requests and their files, and their existing links keep working. A closed portal reopens.

An onboarding portal has no real date, so this direction asks you for one, and it is compulsory. An event quietly dated today would land in the wrong week of every report with nothing on screen to say so. You can set the status at the same time. Because a portal holds no Space and skips the booking rules entirely, this is also the first time the record is tested against your double-booking settings, so a conversion can be refused if the date and Space you have chosen clash with something already there. See Preventing a double-booked Space.

One thing to watch: the conversion saves on its own, straight away. Anything you have typed into the form behind the dialog is not included, so save your edits first, then convert.

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.

Using 1pm for onboarding and compliance requests is the full onboarding workflow a Portal is built for.
Letting crew and guests register themselves covers the self-registration link.
Asking crew for documents and info and Asking everyone for the same thing cover the Requests checklist.
Getting people to accept and sign your terms covers the Terms / Agreement request.
The Requests dashboard and Reviewing crew uploads cover tracking and approving what comes in.
Sending a checklist to crew covers task requests, which work on a portal exactly as they do on an event.
Your crew allowance and account usage covers what an open portal counts as on your plan.
Preventing a double-booked Space covers the check a portal meets for the first time when it converts to an event.