Forty-four elements to build the page from, grouped here by what your clients and their families come looking for.
The two things your clients ring about most, answered on the page instead of over the phone.
One upcoming appointment on its own, or a scrollable list with date tiles, status pills and the detail fields you choose.
A month grid for clients who plan ahead, or a seven-day strip with a dot per appointment.
The support workers rostered on upcoming appointments, so nobody arrives as a stranger at the door.
Time until the next visit, and support hours delivered against a target with a marker.
Funding made legible, so the monthly question stops being a monthly question.
A hero block showing remaining funds, utilisation and the agreement period.
Per-item budget breakdown, each line carrying its own utilisation meter.
The full list, with term, funding source and status.
A radial gauge, and one bar splitting approved funding into utilised, committed and remaining.
The Contact record shown back to the client, with editing allowed only where you allow it.
Single fields or grouped cards, with editable set per field, writing straight back to the Contact record.
Listed for download, so nobody has to ask your team for a copy by email.
Any related list laid out as a table, with the columns and sorting you choose.
A chronological activity feed, plus traffic-light checklists driven by your own field rules.
When a client needs something, it arrives in Salesforce as a record rather than in somebody's inbox.
A published Maica form embedded in the page, prefilled from the client's record and writing back through its own mappings.
Open a form or an external link, with a confirmation prompt where it matters.
Portal requests are logged to a dedicated Salesforce object, so they queue as records your team can work.
Send a titled notification with body text and a link, and see who has read it.
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 pages for grouped navigation, or hide one and keep it reachable by link.
Conditional sections appear or disappear per person based on a field value, so one portal serves clients, families and different programs without maintaining several.
Editable is set field by field. Everything else is a read-only view, so clients can check their details without being able to rewrite the record.
Logo, colours, typography and corner style, plus the welcome and sign-in screens. Serve it on your own domain, with the certificate handled for you.
Elements query Salesforce when the page loads. There is no portal database holding a copy of your client data.
Nothing is exported, mirrored or synced overnight, so there is no second store of client information to keep current, keep safe or explain to an auditor.
Update the record and the portal is already right. No lag, no reconciliation, no explaining why two screens disagree.
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 rather than hard-coded, so it works with your data model instead of demanding a new one.
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}