Custom Portal Studio Discuss a project
Custom portal development One workflow first

Give customers a portal that gets the work done

We build portals for customers, partners, vendors and staff: a place to submit a request, get it approved and see it finished in the system you already run. You see one workflow working with real roles and permissions before deciding anything about the platform behind it.

Map a portal's users, roles and tasksRead the Experience Cloud comparison

Connecting the CRM or ERP you already run is the usual case. Building a new one alongside the portal is welcome too.

One request moving through a portal A customer or partner submits a request. Staff approve it. The approval updates the CRM or ERP record. The person sees the outcome. A failed update goes to an exception queue owned by staff and still ends with an outcome for the person. CUSTOMER OR PARTNER STAFF CRM OR ERP 1 Request On their own account 4 Outcome By portal and email 2 Approval Decided, with a reason ! Exception queue Failures get an owner 3 System update The record staff use ACCOUNT RECORD
How one request moves. The dashed path is the exception route.
The problem 4 situations

A portal that shows status is not the same as one that finishes work

These are situations people describe when a portal was built to be looked at, not used. Yours may be different.

  1. 01

    The portal shows a status. The request still moves by email.

    A customer or partner signs in, sees where things stand, then calls or emails to get something done. The portal became one more place to check, not where the work happens.

    Moves by email
  2. 02

    Every submission gets re-typed into the system of record

    A request lands in an inbox or a ticket queue. Staff re-enter it into the CRM or ERP by hand, because the portal was never connected to write anything back.

    Re-typed by hand
  3. 03

    One login model, several kinds of user

    Customers, partners and staff often need different views of the same account. A portal built for one kind of user leaves someone seeing too much, or asking for access they should already have.

    Wrong access
  4. 04

    Exceptions have nowhere to go

    A payment fails, a document is missing, an approval is declined. In a lot of portals that just ends the interaction, and no one owns getting the person to a working outcome.

    No owner
What gets built 4 roles, 4 connections

One workflow, built as screens, permissions and a connection to your systems

A portal here is the request your customers, partners or staff need to make, with the permission check, approval and record update that finishing it requires.

Who uses itIllustration of a role table
RoleWhat they doSeesSubmits requestsApproves or resolvesSets permissions
Customer, client or partner user Signs in, sees their own account, submits a request, and follows it to an outcome instead of a status. Their own account YesNoNo
Staff who approve and fulfil See exactly the requests waiting on them, approve or decline with a reason, and the source system updates at once. Requests waiting on them NoYesNo
Staff who handle exceptions Pick up a declined payment, a missing document or a failed sync from a queue built for that. The exception queue NoYesNo
Administrator Sets who can see and do what, by role and account, and sees the trail of every change. The trail of every change NoNoYes
What it connects to

  • CRM or ERP

    The system of record. The portal reads and writes to it, not around it.

  • Documents, payments and messaging

    Uploads, invoices and notifications attach to the request they belong to.

  • Identity and SSO

    Each person signs in once, with the access their role and account allow.

  • The platform you already run

    Salesforce, HubSpot or something else keeps running. A portal can connect to it or sit beside a new CRM.

Demonstration Synthetic demonstration: invented records

One request, from submission to a system update

Every record here is invented. The walkthrough shows the kind of request we build most often: a person outside your company asks for something, someone inside approves it, and the system of record changes because of that approval. Nobody re-types anything.

We use an invented scenario because a portal is full of other people's data, and a walkthrough of a real one needs its owner's approval first.

Request recordInvented data

  1. Request

    Submitted
    Partner user

    A partner signs in and submits a change against their own account. The portal only shows the accounts and actions their role allows.

  2. Approval

    Decided
    Staff, account owner

    The request reaches a queue for the staff member who owns that account. They approve, decline or ask a question, with a reason attached.

  3. System update

    Record updated
    CRM or ERP

    An approval writes the change to the CRM or ERP directly, the same record staff already use, not a copy of it.

  4. Confirmation or exception

    Outcome or exception
    Partner user, exception staff

    The partner sees the outcome in the portal and by email. A rejected change moves to an exception queue instead of disappearing.

How it goes 6 steps

Discovery, one request, a pilot, then a decision

Each step produces something you keep, whether or not you continue.

  1. 01

    Discovery call

    You keep

    We learn your roles, systems and the request that matters most. You get a short written summary.

  2. 02

    Map one workflow

    You keep

    A map of one request end to end: who submits it, who approves it, what system it updates, and where it can fail.

  3. 03

    Scoped proposal

    You keep

    A fixed scope for a pilot: what gets built, for which roles, how it is judged and what it costs.

  4. 04

    Working pilot

    You keep

    A small group of your customers, partners or staff use it with real data while the current process keeps running.

  5. 05

    Your decision

    You choose

    You compare the pilot with how the request works today and choose: stop, extend it, or plan a wider rollout.

  6. 06

    Rollout and support

    You keep

    A staged rollout to more roles and accounts, with maintenance agreed in writing.

Ownership and maintenance Agreed in writing

The questions that decide whether this is a good idea

Who owns the code?
You do. It lives in your repository. Where we build on an open-source foundation, we name it and its licence first.
Who maintains it after handoff?
Settled before the pilot, in writing: who upgrades it, who secures it, who answers when it breaks, and what that costs. It can be us, your team, or both.
Do we always build something new?
No. Sometimes the right answer is to configure or extend the portal your CRM already includes. If that is what we see during discovery, we will say so.
Will it connect to our CRM or ERP?
That is most of the work. We map every integration during discovery and test each one in the pilot, including what happens when a sync fails.
Who can see what?
Permissions are built by role and by account, not one shared login. Every request and change leaves a record of who did what.
Where does AI fit?
Inside the workflow, with access to the right records and a person handling exceptions, not as a layer on unchanged screens.
A short decision aid 7 items

Seven things to know before you scope a portal

You can gather these in an afternoon. They make every later conversation shorter, with us or with anyone else. If you are writing requirements, the customer portal requirements worksheet goes through them field by field.

  1. Which roles need the portal: customers, partners, vendors, staff, or more than one
  2. What each role needs to actually do, not just see
  3. Which of those actions are conversations, and which change a record
  4. The system of record for each type of data involved
  5. What happens today when a request fails or gets declined
  6. Whether you plan to keep your current CRM, replace it, or run both for a while
  7. Who would maintain the portal after launch, and whether you have engineers
Read the Experience Cloud comparison
Questions buyers ask 4 questions

Plain answers

Do we have to leave Salesforce or HubSpot to get a real portal?

No. A portal can connect to the CRM you already run. Sometimes the better answer is to configure what you have, and we will say so.

How is this different from a native portal like Experience Cloud?

It depends on what your roles need to do, not just see. The comparison is in the guide, including where a native portal is the right call.

How long does a pilot take?

It depends on the workflow and its integrations. We set the length in the proposal, after mapping, not before.

What does it cost?

We quote a fixed scope once the workflow is mapped. We do not publish a price list, because scope decides cost.

Who you would work with 2 people

The two people you would actually talk to

Custom Portal Studio is a site of The Goodstack Company. There is no sales team and no account manager. David and Vidur are the only two people involved, from the first email through the pilot and the maintenance after it.

David

Engineering and delivery

David runs beLoved Health, a distribution company, and built the system it runs on, including two portals in daily use: one for retailers and one for reps. He has run the part most portal projects underestimate, which is permissions and what outside users are allowed to see and change. He writes the code here and runs the pilots.

Vidur

Product and design

Vidur is the co-founder of Goodstack and leads product and design. He designed the original Goodstack and ran the studio with David. On portal work he owns what a customer or partner sees when they log in, and he has experience with SOC 2 compliance, which matters as soon as a portal holds another company's data.

About Goodstack
New request Draft

Start by mapping one request

Tell us who needs to use the portal, the systems involved, and the request that matters most today. We will reply with what we would look at first.

Map a portal's users, roles and tasksOpens the contact page. Email only, no form.