Run Separate Aurora Workflows for Multiple Advisory Clients

Run Aurora work for multiple advisory clients by selecting the client, account, permitted sources and authorized audience before each assignment. Keep a separate operating record and review queue for each mandate. Naming agents after clients does not isolate their data or authorize access to another person's connected account.

The result is a client-specific work plan with explicit handoff checks, not a promise of a multi-client dashboard or automatic confidentiality enforcement. This recipe includes fictional material and has not been executed as an authenticated Finta demonstration.

Separate the work before separating the roles

Write a short mandate record for each engagement: client and legal entity, objective, accountable adviser, approved readers, permitted sources, excluded material and next deliverable. Use the organization's actual access controls and the client's instructions. A prompt such as “do not mention the other client” is an instruction, not an access restriction.

Finta's current source review distinguishes the agent owner and organization from the sources an assignment may retrieve. Organization Skills and the user's connected App accounts are different resources. Remembered context is governed by the authorized user/organization path and settings. Do not describe this as automatic sharing of all members' private data, or assume that a role's selected resource list creates a confidentiality partition.

Copy a client operating record

Field	Record for this mandate	Check before starting
Client and purpose	Exact organization and bounded advisory outcome	The selected account/context matches this engagement
Authorized sources	Approved document IDs, records and permitted conversations	Each source belongs to this purpose and user
Excluded material	Other clients, restricted advice, superseded drafts	No copied bundle quietly includes them
Responsibility	One prepared output and quality standard	The role cannot broaden the mandate
Reviewer	Named person and permitted audience	The recipient can see this output
Handoff	Accepted facts, artifact version and open questions	No unrelated thread or raw transcript travels
Action boundary	Draft, proposed record change or separately authorized action	Authority is documented for the specific step

A useful client identifier is a stable reference in your approved working record. Do not put confidential names, transcript excerpts or document contents into public URLs or analytics labels. An agent name can make a role recognizable; it cannot replace a source-by-source check.

Fictional example: two briefs with one tempting shortcut

Fictional teaching example. NorthDesk Advisory supports two unrelated software companies. Client A asks for a sourced investor-fit brief. Client B asks for a partnership conversation plan. Both companies work in a broad operations category, but they have different plans, sources and disclosure permissions.

The adviser considers reusing Client A's competitor notes in Client B's brief. The notes include a private customer description and an unannounced product plan. Their apparent relevance does not grant reuse permission. The adviser excludes the notes and uses current public sources plus Client B's approved materials instead.

Return	Accepted evidence	Blocked or excluded	Next human decision
Client A investor-fit brief	Approved company summary and dated public investor sources	Another client's market notes	Review fit and decide whether to research further
Client B partnership plan	Client B product scope and current partner sources	Client A customer description and unannounced roadmap	Approve the mutual-value hypothesis before any approach
Adviser review queue	Two artifact references with separate owners	Combined raw source folder	Review each mandate independently

The assistant's first draft also refers to “our existing customer” without an attributable source. The adviser removes the phrase and asks which supplied record supports it. If the origin cannot be established, the claim stays excluded. Cleaner wording is not a cure for mixed context.

Use an explicit switch procedure

1. Manual: finish or park the current mandate's working artifact and record unresolved items.
2. Manual: confirm the intended user, organization, client and permitted source set for the next task.
3. User-triggered: supply a minimized client brief or retrieve only sources the intended context actually permits.
4. User-triggered: ask Aurora to identify the sources behind its draft and mark inaccessible material.
5. Manual: inspect the draft for unsupported cross-client references, wrong entity, stale documents and unauthorized recipients.
6. Separately authorized: perform any supported approved write or external communication and inspect the receipt.

Where the product cannot provide the separation your engagement requires, do not compensate by inventing a technical guarantee. Use an approved environment and minimized supplied excerpts, or stop until the responsible owner resolves the access question. Do not switch to someone else's account or copy restricted files to bypass a boundary.

Prepare a handoff, not a data dump

Mandate reference and intended recipient:
Accepted artifact/version:
Facts allowed in this next step:
Source references and observation dates:
Excluded or restricted facts:
Unresolved decision and accountable reviewer:
Proposed action and required authority:
What actually happened, or nothing performed:
Next review point:

Keep a source's permitted audience attached when information moves from research to writing. Approval of an internal brief does not automatically approve disclosure in an investor email, client report or introduction request. If a restriction is unclear, return the question to the source owner rather than assuming that the next agent inherits permission.

Apply the same care to routines and history

Before configuring recurring work, confirm its client scope, owner, source coverage, timezone and stopping condition. A schedule is not a new source permission. Any supported routine email recipient authorization is a separate deliberate setting, not granted by this worksheet or an agent role. Inspect actual active state and results; an old successful run does not prove the current source is still connected.

Retiring or duplicating a role should not be described as migrating its conversation or deleting all related history. Use actual controls and policy, retain the working record needed for continuity, and verify the result. Follow the agent-management guide for role lifecycle and the personal-versus-shared guide for the underlying distinctions.

Copyable practice prompt

Try this with Aurora AI in Finta, Claude or Codex using a minimized, permitted client packet.

Prepare [specific deliverable] for [one mandate reference] using only [approved sources and audience]. Return a source-to-claim table, the draft and a separate blocked-items list. Flag wrong entity, unexplained “our/we” references, inaccessible sources, superseded versions and facts whose permitted audience is unclear. Do not use other clients' material or assume an agent name isolates data. Keep instructions, facts and proposed actions separate. Do not change accounts, share files, send messages, alter permissions or enable a routine. End with the exact client/source scope and the human review needed.

Finish with a client-specific receipt

The review is complete when an authorized adviser can explain which mandate the output serves, where each material fact came from, which audience may receive it and what remains unresolved. Aurora and Finta CRM can support that work where the appropriate context and tools are available. They do not replace engagement policy or the adviser's confidentiality decision.

Source review: October 22, 2026. Product boundaries reflect current source and official-page review, not a performed isolation or retention test. The operating record and NorthDesk example are original education, not legal advice or a guarantee of confidentiality.