The multi-client reality
If you're a Workday functional consultant, you probably work across multiple clients simultaneously. Each client has their own Workday tenants, their own Extend developer account, their own custom configurations, their own data sensitivity requirements, and their own project timelines.
Keeping all of this separate is your responsibility. When you introduce AI into the workflow, that responsibility doesn't go away — it gets harder to manage.
The problem with generic AI across clients
Context bleed
You're working on Client A's benefits eligibility rules in a Claude conversation. You get a great explanation including specific field names and business process references from Client A's tenant. An hour later, you switch to Client B. You start a new conversation — or maybe continue the same one.
Claude doesn't know you switched clients. It doesn't know that the field names from Client A don't apply to Client B. It may reference Client A's specific fields in its answer. If you're in the same conversation, Claude has Client A's context in its window and will pattern-match from it.
Credential confusion
Workday credentials are sensitive. Tenant URLs, developer account information, and authentication details are client-specific and often covered by NDAs. When working with generic AI, you might paste WQL queries containing tenant URLs, share error messages with tenant identifiers, reference custom field names that reveal business structure, or discuss confidential security configurations.
Nothing in ChatGPT or Claude ties any of this to a client. A tenant URL pasted for Client A is one message away from a conversation about Client B, and nothing in the tool stops it.
No boundary around actions
Once an AI tool can reach a tenant, the question that matters is which tenant. With a generic tool connected through an integration, nothing ties a conversation to a client: the same chat that answered a question about Client A can be pointed at Client B's credentials by a wrong paste or a wrong guess.
What client isolation actually requires
- Credential isolation — each client's credentials stored separately, served only to conversations for that client. Never by accident, not by user error, not by the AI's request.
- Tenant scoping — a conversation can reach only the tenants of its own client, and only the ones it was given.
- Consent boundaries — permission to perform actions managed per client. Consent resets when the client context changes.
How kiweely handles multi-client work
Clients as a first-class concept
In kiweely, a Client is the customer the work is for. Each can have a name, zero or one Workday Extend developer account, multiple Workday tenants, and its own set of conversations and projects.
Conversation-level client pinning
Every conversation is pinned to a client — either at creation or when its first connection is established. Once pinned, a conversation never changes clients. The AI agent receives only that client's credentials. There is no "switch client" button inside a conversation. Different client means different conversation.
Credential scoping
When the AI agent runs a Workday action, it receives sign-ins for the pinned client's tenants only, and only for the tenants added to that conversation. kiweely enforces this outside the AI: a conversation for Client A cannot get a sign-in for Client B's tenants, whatever it asks for. A tenant's sign-in stays on your computer and is shared by the conversations that use that tenant.
Consent that doesn't cross clients
In-memory consent grants — "Allow for Session" approvals, Full Access mode — are per conversation and clear when connections change. Granting Full Access in a Client A conversation has no effect on Client B conversations.
What the agent remembers
The agent's memory and your workspace span all your clients, the way your own experience does: it can read another client's project files and carries what it learned between them. What it never gets is another client's sign-ins. From a Client A conversation it cannot read from, or change anything in, a Client B tenant.
What this means for your practice
| Question | Generic AI | kiweely |
|---|---|---|
| Can I keep each client's work apart? | Manual discipline only | Yes — each conversation is pinned to one client |
| Are credentials isolated by client? | No — you manage manually | Yes — a conversation only gets its own client's sign-ins |
| Does consent cross clients? | N/A — no consent model | No — per-conversation, clears on connection change |
| Is the separation recorded? | No — conversations aren't tied to a client | Partly — each conversation records its client and connections, not yet as a report you can hand a client |
| Does the AI remember across clients? | Yes — anything in its memory or the context window | Yes — its memory spans your clients, but it can't reach another client's tenant |
| Can one client's tenant be reached from another's context? | N/A — no tenant integration | No — each conversation reaches only its own client's tenants |
The trust you owe your clients
Your clients trust you with their Workday environment. That trust extends to the tools you use. When you introduce AI into your workflow, you're making a decision about how your clients' data is handled.
A tool that doesn't know what a client is can't keep clients separate. A tool that doesn't scope credentials can't prevent cross-client access. A tool that doesn't clear consent across boundaries can't guarantee that an approval for one client doesn't enable actions on another.
The best AI tool for Workday consulting isn't the smartest one. It's the one that's smart enough to know which client it's working for — and disciplined enough to stay in that lane.