Forty-four elements to build the page from, grouped here by what your clients and their families come looking for.
Nothing appears in a portal that your team has not put there. Transparency, without handing over the whole record.
Pages, sections up to four columns, and elements in a grid. Nest a page, or hide it and keep it reachable by link.
Conditional sections appear per person based on a field value, so one portal serves clients, families and programs.
Editable is set field by field. Everything else stays a read-only view of the record.
Logo, colours, typography and corner style, served on your own domain.
Elements query Salesforce when the page loads. There is no portal database holding a copy of your client data.
Update the record and the portal is already right. Every query is filtered to the person signed in, and admin previews return empty rather than somebody else's information. The relationship field used for filtering is set per element, so it fits the data model you already have.
Five ways to sign in, and accounts that provision themselves from rules you already understand. No IT project, no account admin for your team.
A one-time link by email. Nothing to remember and nothing to reset, which matters for older clients.
Standard sign-in, with self-service forgotten-password and reset flows so your team is not the help desk.
An account your clients already have and already trust, with no new credentials to create.
SAML, connected to an identity provider you already run.
Rules against Contact fields with AND and OR logic grant access on sync, and the list stays current as records change. Invite individuals directly when you need to.
A family member or nominee can have their own sign-in to your client's information, with the sections they see controlled by the same field rules.
The questions providers ask us most about giving clients and families access.
No. They sign in to the portal, not to Salesforce. The portal reads and writes their Contact record on their behalf, so there is no licence cost per client.
No. Elements query Salesforce directly when the page loads, so there is no synced copy of client information to keep current, keep secure or account for separately.
Yes. A family member or nominee can have their own sign-in to your client's information, and what they see is governed by the same conditional rules you use everywhere else, so a nominee need not see everything the client does.
In two ways. You choose which elements go on the page at all, and conditional sections can appear or disappear per person based on a field value, so one portal can serve people on different plans and programs.
Only where you allow it. Editable is set field by field, and those fields write back to the Contact record. Everything else is a read-only view, so people can check their details without being able to rewrite the record.
Accounts can be provisioned automatically from rules you define against Contact fields, or you can invite individuals directly. Sign-in options are a magic link by email, a password, Google, Facebook or SAML single sign-on, and you choose which to offer.
Yes. Embedded forms write through their own Salesforce mappings, and portal requests are logged to a dedicated Salesforce object, so a request arrives as a record your team can work rather than an email in somebody's inbox.
Yes. Portals are mobile-first throughout, collapsing to a single column at narrow widths, with touch targets sized for real use rather than resized desktop screens.
%201.svg){kind=icon}
