Skip to content
Resources / GA Applications

Guide / Portals

Define who can see and do what before designing the portal screens.

A customer portal is a secure, role-specific window into selected business records and actions. Before building it, define identity, record-level permissions, authoritative source systems, high-risk actions, support and retention. Start with one complete customer task rather than exposing a large back office through a new interface.

Questionwhat the reader needs
Evidencedefinitions and boundaries
Next stepa useful action path
Why it matters

Audience

Name the user and relationship.

CHAPTER 01

Choose one complete customer task.

A focused first release is easier to secure and test.

01.1

Audience

Name the user and relationship.

01.2

Task

Define the request, review or document action.

CHAPTER 02

Design identity and record permission together.

Login alone does not secure data.

02.1

Access

Limit records by role and relationship.

02.2

Recovery

Protect account and sensitive-action recovery.

CHAPTER 03

Keep source ownership clear.

The portal should not create competing truth.

03.1

Read

Expose only approved current data.

03.2

Write

Validate actions and show the result.

Continue through the resources system.

Each route answers a different operating question while retaining the same standards for evidence, responsibility and a usable next step.

Questions worth resolving

What to clarify before committing.

Do users always need passwords?
No. The identity method follows risk, frequency and task scope.
Can a portal connect to CRM?
Yes when the integration and record permission boundary are defined.

Bring the real problem

Define one secure portal task.

Bring the audience, record source and action that matters.