Skip to content
Journeybee Help Center home
InboxAsk a human

Portal Settings

Portal Settings is where you set the rules that apply to your partner portal as a whole: what new partnerships start with, how people get access to the portal, and the plumbing for embedding it in your own site.

Where to find it: Go to Settings, then Portal Settings (under Workspace).

Who can use this: Admins only. The page is not visible to other roles.

The page has five sections. Custom Domain has its own article, Custom Domains; the other four are covered here.

Partnership Settings Template

These are the defaults applied to every new partnership. They are a starting point, not a policy: each one can be overridden on an individual partner from the Settings tab of that partner's page.

Changing a default here does not retrospectively change existing partnerships.

Deal Expiration (days)

How many days a deal lasts before it expires, counted from when it is created. Leave it blank and deals never expire.

Expiry is useful with referral partners: a lead that has sat untouched for 90 days is usually not coming back, and expiring it keeps your pipeline honest.

Allow partners to edit deal values

Whether the partner can change the value on a deal in their portal. Disable it if the number should only ever come from your side.

Allow partners to edit lead status

Whether the partner can move a lead's status themselves.

Allow partners to edit deal stages

Whether the partner can move a deal along your pipeline. Most programs disable this, because pipeline stage is a sales judgement rather than a partner one.

Limit partner visibility to assigned items

With this on, each partner user only sees the leads, deals and cards they created or are assigned to, rather than everything belonging to their company.

This matters for larger partners. A reseller with fifteen salespeople usually does not want every rep seeing every other rep's pipeline.

Partner Portal Access

Three settings that control how people get into your portal in the first place. All three apply to sign-in through your custom domain, and all three stay disabled until you have one connected.

Allow automatic user creation

Someone whose email domain matches an existing partner's company domain gets portal access automatically, with no invitation.

So if acme.com is a partner and a new person at jane@acme.com signs in, they are in. It saves you inviting each new person at a partner one at a time.

It only works for company email domains. Public providers such as Gmail and Yahoo are excluded, because a shared public domain would let anybody in.

Request access to the partner portal

Adds a Request Access option to your portal login page. Someone who is not yet a partner can submit a request, and your admins are notified by email and in-app.

This is the light-touch alternative to a full application form: the person tells you who they are, and you decide.

Allow public email domains on applications

Whether applications from Gmail, Outlook and other public providers are accepted.

Off is the stricter and more common setting: applicants must use a work email address, and public-domain applications are rejected with a message asking them to reapply from their company address. Turn it on if you genuinely partner with sole traders and individuals.

Embedded Portal Domains

The allowlist of your own sites that are permitted to load the partner portal in an iframe. Anything not on this list is blocked from framing the portal.

Add bare hostnames, one at a time: www.acme.com, not https://www.acme.com/partners. No protocol, no path, no port.

There is a maximum number of allowed domains, and the page tells you if you reach it.

This section needs the Embedded Portal module. Without it, the section is visible but disabled.

Embed Signing Keys

Embedding the portal uses trusted token handoff: your backend signs a short-lived token for a user it has already authenticated, and the portal exchanges it for a session. The partner is signed in when the iframe loads, with no second login.

Signing keys are the secret your backend signs those tokens with.

Creating a key

  1. Give the key a name that identifies where it will live, such as "Production backend".

  2. Click to create it.

  3. Copy the key immediately. It is shown once and never again.

Treat it exactly like a password. It belongs in your server-side secret store. A signing key in browser code would let anyone mint a token for any of your partners.

Just-in-time provisioning

Each key has its own JIT switch. With it on, a signed token for an unknown user creates their partner account on the spot. With it off, the token only works for people who already have portal access.

Leave it off unless your own system is genuinely the source of truth for who should have access.

Managing keys

Each key shows as Active or Revoked, and when it was last used, which is how you spot a key nothing uses any more.

Revoke is immediate: any backend still minting tokens with that key stops working straight away. To rotate a key safely, create the new one, deploy it, confirm the new key's "last used" is ticking over, then revoke the old one.

This section also needs the Embedded Portal module.

For your developers

The technical reference for embedding, including the SDK, the token contract and the security model, is at docs.journeybee.io/guides/embedding-portal.

Troubleshooting

The portal access toggles are greyed out

They need a custom domain. Connect one in the Custom Domain section on the same page, then reload.

The embed sections are greyed out

Embedded Portal Domains and Embed Signing Keys need the Embedded Portal module. Contact Journeybee support to have it enabled.

A domain will not save

It has to be a bare hostname. Strip the https://, any trailing path, and any port number.

I lost a signing key

It cannot be retrieved. Create a new one, deploy it, then revoke the old one.

The portal will not load inside our site

Check the host page's exact hostname is on the Embedded Portal Domains list. acme.com and www.acme.com are different entries.

I changed a default and nothing happened to existing partners

That is correct. The Partnership Settings Template applies to new partnerships. Change an existing partner from the Settings tab on their own page.

Good to know

  • Custom domain, embedding, and portal SSO are three separate things. You can use any combination.

  • Automatic user creation and Request Access solve the same problem from opposite ends: one lets known partner domains straight in, the other asks unknown people to knock.

  • Set the partnership template before you onboard in volume. It saves editing the same four settings on every partner.

  • Give each signing key a name that says where it runs. "Key 2" tells you nothing when you are deciding what is safe to revoke.

Related articles