Portals

A portal is a small app you give to people outside your team. They sign in with their own email and password and see only the records that belong to them: their jobs, their invoices, their tickets.

It is not an InfoLobby account. Your portal users never see your workspaces, your other tables or each other. They see the screens you built, filtered to their own rows, and nothing else.

Who a portal is for

Anyone who needs to see their own slice of your data without joining your team:

  • clients checking the progress of their jobs
  • contractors looking at the work assigned to them
  • partners reviewing referrals they sent you
  • members checking their own renewal dates

You are not charged per portal user the way you are charged per team member. Your plan sets how many portals you can run and how many people can sign into them each month.

How sign-in works

Here is the idea that makes everything else simple: a portal user is a record in one of your tables.

If you have a Clients table, each row in it can be a login. The email address on the record is the username. A Password field on the same record holds their password, hashed so nobody, including you, can read it back.

That means there is no second list of people to keep in step with the first. Change the company name on the record and the portal shows the new one. Set the record's status to Cancelled and they are signed out everywhere on their next click. Delete the record and the login is gone.

Building one

Open Portals from the user menu (the person icon, top right), then New Portal.

Before you start, you need an SMTP integration. A portal emails your clients their sign-in details, and it sends through your own mail server rather than ours, so your messages arrive from your domain and your deliverability stays yours. Set one up under Integrations first. InfoLobby will not create a portal without one.

1. Pick the sign-in table

On the sign-in screen, choose:

  • Sign-in table: the table your portal users live in, for example Clients.
  • Email field: the text field holding their email address.
  • Password field: a Password field on the same table. Add one in the table's Configure screen first if it does not have one.
  • Display name field: what to call them once they are signed in, for example Company.
  • Who may sign in: a filter, for example Status is Active. This is checked on every single request, not just at sign-in, so deactivating someone takes effect immediately.

Under Signing up, and getting back in on the same screen are three switches:

  • Let people change their own password: adds a Change password link to the portal header. Leave this on. The passwords a portal emails are generated, and this is how somebody replaces theirs with one they will remember.
  • Let people ask for a new password by email: adds "Forgot your password?" to the sign-in screen. See Lost passwords below.
  • Let people sign themselves up: see Sign-up forms below.

2. Add screens

Screens appear in the portal's menu in the order they appear in the list on the left. Drag them to change it. The sign-in screen stays at the top and is never a menu item.

Each screen is one page in the portal. There are five kinds:

  • Text: a page of your own words. A welcome page, contact details, opening hours.
  • List: rows from one of your tables, as a table or as cards. Shows 10 rows a page by default, with Previous and Next; change it under Rows per page.
  • Record: one record in detail, opened by clicking a row on a list.
  • Form: lets a visitor add a record. A request, an order, a support ticket.
  • Sign in: every portal has exactly one, and it is always there.

3. Add your own wording

Every sentence the portal says to your clients is yours to change. Open Portal settings, then Wording: there is a box for each one, grouped by where it appears (signing in, signing up, lost passwords, changing a password, messages, comments). Each box shows our wording as a placeholder. Type over it to use your own, or clear the box to go back to ours.

That covers the field labels too, so a portal can be entirely in a language other than English.

On top of that there are two levels of your own page content, both Markdown, and tokens work in all of them:

  • Header and footer (Portal settings, at the top of the screen list): shown on every screen. The header has two versions, one before someone signs in and one after, so you can greet them by name.
  • Heading and footer on each screen, including the sign-in screen: shown above and below that screen's content. Look under "Heading & footer".

4. Scope every list

This is the part to get right, and the builder will not let you save until you have.

A portal runs with your own access to your own data. Nothing else limits what a screen can show. The filter you put on a list screen is the only thing deciding which rows a visitor sees.

Every list and record screen has one control for this:

Which rows this visitor sees: Only rows where Client is the signed-in visitor

Pick the field that connects those rows to the person signing in, and you are done. If your table already has a relationship pointing at your sign-in table, it is chosen for you.

That is all most portals need. Behind the scenes it writes a filter using {{portal.record_id}}, which means "the record of whoever is signed in": if Acme Ltd is row 12 in your Clients table, the filter becomes "Client is 12" for them and "Client is 13" for the next person.

For anything beyond that, Extra filters takes the same conditions you use elsewhere in InfoLobby, and you can use tokens in a value. You do not have to remember their names: type {{ in any value box and a list appears, the same way it does in automations.

If you leave a list unfiltered, InfoLobby refuses to save it and tells you which screen is the problem. You can override that with the Show all rows tick box, but only do it for a screen where every visitor genuinely should see everything, like a price list.

5. Let people fill things in

By default a portal is read-only. Two settings change that.

Editing a record. On a Record screen, tick Let visitors edit this record, then tick editable next to each field they may change. Everything else stays read-only, and a field you did not tick is not just hidden from the form: a value sent for it is thrown away on the server, so there is nothing to get around.

Set automatically on the same screen fills in fields whenever a visitor saves, after their own changes and overriding them. Use it to stamp who last touched a record, or to move it to a status of your choosing:

Status is Updated by client

That works even on a field you left read-only, which is the point: the visitor cannot pick the status, you decide what their editing means.

Some field types are never editable from a portal, and are marked view only in the list:

  • Lookup fields, because choosing a value means searching the table they point at, and that search would not be limited to the visitor's own rows.
  • Team member fields, because a portal visitor is not a member of your team.
  • Signature fields, because signing a document from a portal is a bigger decision than ticking a box, and it is coming separately.
  • Rich text fields, because the editor they need is too heavy for a public page. Plain text, Markdown and JSON formats are all editable.

Adding a record. Click Add screen, name it, and pick the type Form. Choose the table and tick the fields the visitor fills in. Then open the list those records belong to and set Visitors can add a record using to your form. That is all: a New button appears above the list, on the portal itself.

(That dropdown only lists Form screens, so it stays empty until you have made one.)

A form has one setting that matters more than the rest:

Set automatically: Client is {{portal.record_id}}

This is what ties the new record to whoever created it, the same way a list's filter ties rows to whoever is reading them. If your table has a relationship pointing at your sign-in table, it is filled in for you as soon as you pick the table. It is applied after the visitor's answers and overrides them, so nobody can submit a form that files a record under somebody else's name. Use it for status and source values too, so a new request always arrives as, say, Status: New.

Leave it out and InfoLobby will still save the form, with a warning: the records it creates will not show up on that visitor's own screens, because nothing connects them.

Files. Tick a File field as editable, or put one on a form, and the visitor gets a file picker. Uploads are added to whatever is already on the record, never replacing it, and a visitor cannot remove a file someone else attached. Files already on a record are shown as links they can open; those links expire after fifteen minutes, so a link copied out of the page does not keep working forever. The limit is 15 MB a file.

Required fields. Tick required next to a field and the visitor cannot submit without it. A field you marked required but left read-only never blocks anything, since they have no way to fill it in.

6. Turn on comments

A Record screen can show that record's comment thread, so a client can ask a question and your team can answer it in the place the answer belongs.

Open the Record screen, expand Comments, and choose:

  • Show this record's comments to visitors puts the thread on the page.
  • Let visitors post comments adds a box they can write in.
  • Let visitors attach files to comments adds a file picker to that box.

Each one needs the one above it, so a thread can be read-only.

Read this before you turn it on. There is one comment thread per record, and it is the same thread your team sees inside InfoLobby. Turning this on shows the visitor every comment already on that record, including notes your team wrote for each other. Nothing marks a comment private, so there is nothing InfoLobby can filter out for you. If a table's comments are where your team thinks out loud, leave this off.

Emails logged against a record are never shown. Those stay internal.

A visitor's comment is posted under the portal's name and theirs, for example Acme Portal: Acme Ltd, so your team can see at a glance that it came from outside. Inside the portal they simply see their own name.

Mentions do not cross either way. A visitor cannot notify one of your team by name, and a mention your team wrote reads as plain text on the portal.

The rest behaves the way the rest of a portal does. A comment is checked against the same filters the record is, so a visitor can only read and write on a record they could already open. Attachments are limited to 15 MB a file, and the links to them expire after fifteen minutes.

Automations fire on a comment from a portal exactly as they do on any other, so an On Comment Added flow can email whoever needs to know.

7. Drill down

Set a list's Clicking a row opens to a Record screen, and rows become clickable.

You can go a level deeper. Say a client picks a job, and you want a Milestones screen showing only that job's milestones. Filter the Milestones list by:

Job is {{portal.current:<your Jobs table>}}

That means "the job they just opened". InfoLobby remembers it for the length of their visit.

If they reach that screen without having picked a job, they get a short message asking them to pick one. They never see every milestone in the table. That is deliberate: when a filter cannot work out who or what it applies to, the screen shows nothing rather than everything.

8. Publish

Give the portal a web address (/portal/your-name) and click Publish. Share the link.

Portals are never indexed by search engines.

Giving someone their login

Open Portal settings, then Send someone their login. Search for them, press the button, and InfoLobby generates a password, saves it to their record and emails it to them once. Nobody, including us, can read it back afterwards, and any session they already had is signed out.

The message it sends is yours: Portal settings, then Email, then Welcome email. It has to keep the {{portal.password}} token somewhere in the body, or the password will not be in the email.

You can still do it by hand if you prefer. Open their record, type into the Password field, save, and tell them what it is.

Lost passwords

Turn on Let people ask for a new password by email and the sign-in screen gets a "Forgot your password?" link. Someone who uses it types their email address and, if that address has an account and still passes your "Who may sign in" filter, gets a freshly generated password.

Three things happen on purpose:

  • Every session for that person is signed out. A reset is what somebody does when they think their access has been taken, so nothing from before it keeps working.
  • The answer is always the same. Whether or not the address has an account, the page says the same sentence. A portal must not be usable as a way to find out who your clients are.
  • Deactivated people get nothing. If your "Who may sign in" filter excludes them, no email is sent, and the page still says the same sentence.

Sign-up forms

A sign-up form lets somebody create their own account. Add a Form screen, set This form to "Let people sign themselves up", and choose it under The sign-up form is on the sign-in screen.

A sign-up form is different from an ordinary form in ways the builder handles for you:

  • it always creates records in your sign-in table, and it is always public;
  • it always carries an anti-bot check;
  • the Password field is never on it. Either InfoLobby emails a generated password, or it adds its own "choose a password" box, depending on the Password setting.

Put the email field on it, plus whatever else you need to know. Use Set automatically to stamp anything the visitor should not choose, like a status or a source.

Approving new sign-ups. Tick "New sign-ups need approving before they can sign in", and stamp a status your "Who may sign in" filter excludes (for example Pending). The record is created, nothing is emailed, and nobody can sign in until you change that status. Send them their login when you are ready.

An address that already has an account is answered exactly like a new one, and nothing happens behind it. That is deliberate, for the same reason as the reset form.

Off by default, and worth understanding before you turn it on.

A sign-in link is a one-use link you email somebody instead of a password. There is no separate place to keep it, so the live link token is stored in a field on your own sign-in table. Anyone who can read that field can sign in as that person until the link is used or expires.

Because of that, InfoLobby will not save the setting unless the field you choose is a text field marked Always Hidden, and is not on any web form. Always Hidden also keeps it out of views and off embeds.

The link works exactly once. Using it, letting it expire, or sending a new one all kill the old one. Send one from Portal settings, then Send someone their login.

Emailed passwords are the safer default, and most portals should stay with them.

Signed in now

The portal builder shows who is signed in right now, and lets you revoke any session immediately. A revoked session stops working on the visitor's next click, on every device.

What a portal cannot do (yet)

Coming next:

  • inviting a whole filtered list of people at once, rather than one at a time

A portal visitor can never delete a record, and never will in this release.

Things worth knowing

Record locks do not apply inside a portal. A record lock points at a member of your team, and a portal visitor is not one, so the lock has nothing to match on. The portal's own filters are what scope a portal. If you point a portal at a locked table, InfoLobby asks you to add a filter and will not save without one.

Automations run normally. Anything a portal user does that changes data fires your automations just as a change from inside InfoLobby would. Activity history records the write as coming from the portal, and names the person.

Password fields never appear on a portal. Even if you add one to a screen, it is dropped before the page is built, and a sign-up form is not allowed to carry one.

Emailed passwords are generated, never chosen. That is the point: a password we made up is not one somebody reused from their bank. The email says so and asks them to change it after signing in, which is why "Let people change their own password" is on by default.

Portal email goes through your mail server, not ours. Choose the SMTP integration under Portal settings, then Email. The address it sends from comes from that integration; you choose the name beside it.

A record is re-checked every time, including on save. If a job moves to another client while that client has the page open, their next click says the record cannot be found. Nothing they held onto from before still works.

  • Password Fields: the credential a portal signs in against
  • Web Forms: collect data from people who do not need a login
  • Embeds: show a read-only table on your own website