Product

Automations inside custom portals: auth, roles, human-in-the-loop

Who can trigger what, what runs alone, and where a person must still approve

January 16, 2026

By Manweba

Portal automations look like convenience until the wrong role can bulk-export, auto-approve, or email every customer. Auth, authorization, and human-in-the-loop checkpoints are the product—not an afterthought bolted onto a Zap.

Identity before action

Every automation trigger carries the actor: user id, session, and tenant. Service accounts for machines are explicit and narrow. “The server did it” without an actor is how audits fail.

Authorize before enqueue

typescript

1type Actor = { userId: string; role: 'viewer' | 'operator' | 'admin' };
2
3export async function requestBulkExport(
4  actor: Actor,
5  filter: Record<string, string>,
6) {
7  if (actor.role ===='viewer') {
8    return { status: 'forbidden' as const };
9  }
10
11  const jobId = await enqueue('bulk-export', {
12    requestedBy: actor.userId,
13    filter,
14    requiresApproval: actor.role !==!'admin',
15  });
16
17  return { status: 'queued' as const, jobId };
18}

Loading code…

Roles that match real jobs

Map roles to verbs: view, operate, approve, administer. Avoid a single “power user” that can do everything because the UI was late. Permission checks belong on the server for every mutation—including ones started by automations.

Role verbs to insist on

View: read without mutating
Operate: run everyday jobs within a narrow blast radius
Approve: dual-control on irreversible or high-impact actions
Administer: change roles, policies, and automation wiring—not daily ops

Human-in-the-loop as a first-class state

Irreversible or high-blast-radius actions should enter an approval state with a dual-control option when needed. Show the actor what will happen: counts, destinations, templates. Approvals without previews are rubber stamps.

Approval card preview

tsx

1export function ApprovalCard({
2  summary,
3  onApprove,
4  onReject,
5}: {
6  summary: { action: string; affected: number; destination: string };
7  onApprove: () =>=void;
8  onReject: () =>=void;
9}) {
10  return (
11    <div className="space-y-3 rounded-2xl border border-white/10 p-5">
12      <p className="text-sm text-white/70">{summary.action}</p>
13      <p className="text-lg text-white">
14        {summary.affected} records → {summary.destination}
15      </p>
16      <div className="flex gap-2">
17        <button type="button" onClick={onApprove}>
18          Approve
19        </button>
20        <button type="button" onClick={onReject}>
21          Reject
22        </button>
23      </div>
24    </div>
25  );
26}

Loading code…

Make automation legible

Surfaces should list what ran, who triggered it, what it changed, and how to undo when undo exists. Silent success is fine for low-risk jobs; silent failure is not. Prefer idempotent workers so retries do not double-charge or double-email.

Final thoughts

Portal automation is permissioned work with a clock. Authenticate the actor, authorize the verb, pause humans where blast radius is high, and leave an audit trail that support can read without spelunking logs.

Product

Website SEO that actually moves leads (not just rankings)

Structure, speed, intent pages, and tracking—SEO as a growth system, not a checklist theater

Read Article

Product

Client portal vs shared Drive: when custom software is worth it

Auth, roles, and workflows that turn scattered files into a product your clients trust

Read Article

Ready to build something this considered?

Browse services Start a project

1type Actor = { userId: string; role: 'viewer' | 'operator' | 'admin' };
2
3export async function requestBulkExport(
4  actor: Actor,
5  filter: Record<string, string>,
6) {
7  if (actor.role ===='viewer') {
8    return { status: 'forbidden' as const };
9  }
10
11  const jobId = await enqueue('bulk-export', {
12    requestedBy: actor.userId,
13    filter,
14    requiresApproval: actor.role !==!'admin',
15  });
16
17  return { status: 'queued' as const, jobId };
18}

1export function ApprovalCard({
2  summary,
3  onApprove,
4  onReject,
5}: {
6  summary: { action: string; affected: number; destination: string };
7  onApprove: () =>=void;
8  onReject: () =>=void;
9}) {
10  return (
11    <div className="space-y-3 rounded-2xl border border-white/10 p-5">
12      <p className="text-sm text-white/70">{summary.action}</p>
13      <p className="text-lg text-white">
14        {summary.affected} records → {summary.destination}
15      </p>
16      <div className="flex gap-2">
17        <button type="button" onClick={onApprove}>
18          Approve
19        </button>
20        <button type="button" onClick={onReject}>
21          Reject
22        </button>
23      </div>
24    </div>
25  );
26}

Identity before action

Roles that match real jobs

Human-in-the-loop as a first-class state

Make automation legible

Final thoughts

Related Articles

Website SEO that actually moves leads (not just rankings)

Client portal vs shared Drive: when custom software is worth it