Sharing Your Portal

Portal URL

Every portal gets a unique, shareable URL. The format is:

https://www.collabportals.com/your-portal-slug

The slug is auto-generated from your portal name with a short unique suffix (e.g., client-tracker-x7k2m9). You can find your portal URL on the portal settings page.

Sharing the Link

Share your portal URL with end users however you prefer: email, Slack, embed it on your website, or include it in onboarding materials.

There's no limit on how many people can use the link. Access is controlled by whether the person's email exists in your user table, not by the URL itself.

How End Users Log In

Portal users don't need a CollabPortals account or an Airtable account. By default they authenticate with a simple email verification flow:

1. 1

   Visit the portal URL

   The user opens the portal link and sees a login screen with an email input.

2. 2

   Enter their email

   The user enters their email address. This must match an email in the portal's user table.

3. 3

   Receive a verification code

   CollabPortals sends a 6-digit verification code to their email address.

4. 4

   Enter the code

   The user enters the verification code and gains access to the portal.

You can drop the code step. Under Login in the portal's settings, switching off Require an email login code signs people in on their email address alone. It is faster, and it means anyone who knows a user's address can sign in as them, so it suits portals whose data is not sensitive. See Portal User Authentication.

Making a Portal Public

By default nobody sees anything in a portal until they sign in. Under Login in the portal's settings, Make this portal public changes that: anyone with the link can browse the portal without signing in. Use it for a directory, a catalog, a job board, or anything else you want people to find.

Visitors can look but not change anything. They see what your default role sees, with these limits:

• Only tables set to show all records. A table that shows people only their own records stays private, because a visitor has no records of their own.
• Never your user table. Visitors cannot open the list of your users, even if signed-in users can see each other.
• No embed pages. A page that frames another site is for signed-in users only.

Before you save, the setting lists exactly which tables will be public and which stay private.

Fields that show data from other tables

On a public table, visitors see every field your default role can view. That includes fields Airtable fills in from somewhere else: a lookup, a rollup, a formula, a button, or a link to a record in another table. If a public Jobs table has a lookup of each owner's country from your user table and your default role can view it, visitors see the country.

A link to a record in a table that stays private shows that record's name. Visitors cannot open it.

Lookups, rollups, and formulas are viewable from the day you create a portal, so a field like "Owner email" can be on without you having chosen it. Before you save, the setting names each field visitors will be sent that shows data from a table they cannot open. To keep one of them to signed-in users, turn off View on that field for your default role, and give signed-in users a role that can see it. Two kinds of field are sent whatever View says, and the list marks them: the field a table uses as its record name, and the field a gallery, kanban, or calendar page is laid out by. Change the record name or the page's layout to hide those.

Visitors cannot filter by a link field when the linked table uses a record name other than its primary field. Airtable filters a link by the linked record's primary field, so the filter would show that value to visitors.

Signing in on a public portal

If your portal has roles, visitors see a Sign in button. Signing in gives a person their own role, with whatever it lets them see and edit. If you have also turned on self-registration, a Sign up button sits next to it, so a visitor without an account can create one.

If your portal has no roles, making it public removes the sign-in. Nobody can add, edit, or delete records from the portal, and tables that show people only their own records cannot be reached. Add a role if you want both a public view and a sign-in.

Search engines

A public portal can appear in Google and other search engines, records included. That is on by default, because being found is usually the point. It uses more of your Airtable API requests, because search engine bots crawl your pages to list them. Switch off Let search engines list this portal if you only want to share the link yourself. Search engines can take weeks to drop pages they have already listed.

To hand your pages to a search engine directly, your portal has a sitemap at /your-portal-slug/portal-sitemap.xml, or /portal-sitemap.xml on a custom domain.

Keeping Airtable requests down

Every signed-in page view reads live from Airtable. Public pages work differently: visitors see a saved copy of your data, refreshed every 5 minutes, so a busy public page does not use up your Airtable API requests.

Refresh public pages every sets how long that copy is kept, from 1 minute to 1 hour. A longer time uses fewer Airtable requests, and changes you make in Airtable take up to that long to show. A table view with more than 100 records is read live as visitors page through it; grouped tables, kanban, calendar, and FAQ views are saved whole. If you have just edited something and want it live, Refresh now updates the public pages straight away.

People who are signed in always see live data.

What Happens After Login

Once authenticated, the user sees the portal's tables and data based on the permissions you've configured:

• Only tables with view permissions enabled are visible
• On a table scoped to its owner, they see the records that belong to them; on a table set to show everyone all records, they see the lot
• Field visibility is controlled by your field permission settings
• Create, edit, and delete buttons appear based on table permissions

Common Scenarios

Sharing with Clients

Send the portal link directly to clients via email. Each client sees only their own records on the tables you have scoped to their user record. Check the ones you have not: a table with no path to your user table shows everyone the same rows. See Record Ownership.

Embedding in Your Workflow

Include the portal link in automated emails, project kickoff documents, or your own app. The link stays the same even as you update portal permissions.

Embedding the Portal in a Page You Run

A portal can also be embedded in an iframe on a site of your own, so it appears inside your existing members area or client dashboard rather than as a separate destination. See the embedding feature page for what it does.

In the portal's settings, Allow this portal to be embedded takes the sites you will embed into, one per line, each starting with https://. Leaving it empty keeps iframe support off, which is the default.

Two behaviors to know before you use it:

• The login session is issued per embedding site. Signing in inside the iframe is a separate session from signing in on the portal directly, so signing in on one does not sign the user in on the other.
• The sites you list may call that portal's API directly, so list only sites you control. The list is not what stops other people from framing your portal, since any site can put a public URL in an iframe. It decides which sites the portal will accept direct API calls from.

Team Access

For internal teams, share the link in Slack or your intranet. Use role-based access to give different team members different permission levels.

Prerequisites for End Users

Before sharing your portal, make sure:

1. Users exist in the user table - Each person's email needs to be in the user table you selected when creating the portal, unless you have turned on self-registration and want people to add themselves
2. Per-user tables are linked - On a table where each person should see only their own records, link each record to its user. A table set to show everyone all of its records needs no links
3. Permissions are configured - Set up table and field permissions so users see the right data

Next Steps

• Portal User Authentication - Technical details on the login flow
• Custom Domains - Serve the portal on your own domain instead of a collabportals.com URL
• Table Permissions - Control what users can see and do
• Record Ownership - Decide which records each user sees
• Role-Based Access Control - Set up different permission levels