What Client-Level Permissions Should a Multi-Client Agency Intent Data Portal Include?

The client outcome: the right action, in the right workspace, under the right authority

Client-level permissions should prevent four predictable failures: one client seeing another client’s records; an analyst activating data without approval; a former employee retaining access; and an operator changing a sensitive rule without understanding the impact. The promise is not “military-grade access.” A measurable promise is: “Every user has one or more documented roles, each role maps to explicit actions and client workspaces, privileged access expires or is reviewed, and onboarding, change, and offboarding tests prove the intended boundary.”

Start with actions, not job titles. “Marketing manager” means different things across clients. Define whether a role can view topic trends, view company signals, view named contacts, change filters, configure identity, create reports, share links, export data, prepare an audience, approve activation, write to CRM, manage users, manage credentials, change billing inputs, or delete records. Then group compatible actions into roles.

A practical agency and client permission matrix

A useful client-level-permissions framework includes these baseline roles.

• Agency owner: manages agency-wide commercial settings and appoints privileged administrators. It should not use daily super-admin access for routine client delivery.
• Agency platform administrator: configures integrations, credentials, workspace provisioning, and access policy across approved clients. Separate this from client billing and from routine campaign decisions where possible.
• Agency operator: reviews signals, prepares reports, resolves data-quality exceptions, and proposes activations within assigned client workspaces. It should not grant itself new clients or approve its own high-risk change.
• Client administrator: manages the client’s users and approved workspace settings, but cannot view another client or agency-global configuration.
• Client analyst: views signals, reports, and permitted evidence; may create filters or drafts without exporting people or activating destinations by default.
• Client activator: prepares CRM, outreach, or advertising actions from eligible records. For sensitive workflows, require a separate approver.
• Client approver: accepts, rejects, or pauses proposed activations and records a reason. Avoid combining approval with credential administration.
• Executive or read-only reviewer: sees approved summaries and outcomes, with no configuration, export, user-management, or activation rights.
• Temporary specialist: receives time-limited access to a narrow client and function for implementation or support. Expiry should be automatic where the platform supports it and manually verified otherwise.
• Service account: has a nonhuman identity, minimum destinations and fields, named owner, credential-rotation plan, and no interactive reuse.

For each role, mark allow, deny, approval required, or not applicable across view, configure, export, activate, administer, and delete. Add columns for client scope, data sensitivity, authentication requirement, time limit, reviewer, and evidence. Default to deny. Avoid wildcard client access for agency operators unless they truly deliver every account.

Set context-sensitive controls

A permission should consider more than the action. Viewing an aggregate company trend is lower consequence than downloading named contacts. Changing a topic list can change service cost and scope. Editing a suppression list can create compliance exposure. Sharing a bearer report link may grant whoever holds it access; it is not equivalent to a named portal user. Browser automation or an agent acting under a user session should have the same or narrower authorization than the person who approved it.

The NIST Privacy Framework can help teams structure privacy-risk governance, while the OWASP Logging Cheat Sheet provides useful evidence concepts. Neither proves a platform has granular RBAC, tenant isolation, or an audit trail. Map the guidance to the deployed product, contracts, jurisdictions, and client risk with appropriate reviewers.

Implement onboarding, changes, reviews, and offboarding

First, inventory data and actions by workspace. Include topic reports, website events, identity candidates, enriched contacts, filters, suppression, exports, audiences, CRM writes, workflow instructions, credentials, support access, and deletion. Mark which actions are reversible and which can expose data or communicate externally.

Second, create a role request with client, business purpose, required actions, approver, start, expiry, and conflict checks. The client administrator should approve client access; the agency should approve its own privileged operations. Do not grant all-client access merely to reduce administration.

Third, test from the user’s perspective. A client analyst should attempt an allowed view and a prohibited export. An agency operator assigned to Client A should attempt to search for Client B. A revoked user should fail through direct URLs, saved links, API credentials, exports, and browser sessions. Test invitation errors, duplicate emails, changed domains, stale tokens, shared report links, and service accounts.

Fourth, review access on a cadence tied to risk. Privileged and temporary access may need more frequent review than read-only users. Trigger an immediate review after staff departures, client ownership changes, suspicious behavior, new destinations, mergers, or contract changes. Record the reviewer and remediation without assuming the platform supplies a general audit log.

Fifth, offboard completely. Disable named and service accounts, revoke tokens, remove group membership, invalidate report links where supported, rotate shared credentials, stop queued automations, transfer permitted outputs, and verify that support staff no longer have access. A screenshot of a disabled user is not proof that every downstream credential was revoked.

The staffing model usually includes a service owner, platform administrator, client administrator, delivery operator, and privacy or security reviewer. The handoff should give the client a role glossary, matrix, request route, approval rules, review cadence, emergency access process, and offboarding checklist. Any response target belongs in a written service agreement; reviewed sources do not establish a BrandWell permissions SLA.

Five options to evaluate against the same permission criteria

Disclosure: This is a Brandwell-owned resource. Brandwell is the publisher’s product; all options are evaluated using the same disclosed criteria.

BrandWell is first because this resource is BrandWell-owned, not because the sequence proves a universal ranking. Require each provider to demonstrate the same permitted and prohibited actions using at least two client workspaces, then reconcile the behavior with current documentation and contractual scope. Competitor names below receive no outbound links.

1. BrandWell

Intended audience and use case: BrandWell is being developed as a separate agency-reseller intent-data offer for agencies that want branded client delivery and control of their client commercial relationships. It is not the legacy BrandWell SEO writer.

Signal/data coverage and freshness: Public materials describe topic reports, research signals, visitor resolution, identity, enrichment, validation, audiences, portals, and workflows. Those categories are not proof of role granularity, client separation, or specific entitlements. Verify fields, refresh, and workspace boundaries.

Identity resolution and validation: Identity and intent are probabilistic. Permissions should limit who can view named data, change thresholds, accept a match, override validation, and activate an identity. Demand a controlled test.

Integrations and activation: BrandWell can deliver agent-ready automation workflow instructions for Claude and ChatGPT, with optional browser execution through Moxby. Moxby is a separate browser-first product. Verify whose credentials are used, which fields and destinations are authorized, and whether execution requires approval.

Implementation effort: A $70 seven-day reseller pilot is intended to generate branded topic reports, subject to current written product scope. Use it to test two-client separation and the proposed role matrix, not to presume granular RBAC exists.

Privacy and governance: The agency controls retail pricing and end-client billing; BrandWell bills the agency. Role assignment, legal basis, client support, report sharing, and compliance duties must be allocated for the actual deployment.

Verified pricing and total cost: BrandWell public pricing is quote-based. BrandWell agency plans range from $2,500 to $5,000 per month, depending on topic count, term, and available contractually scoped topic exclusivity. The current written quote and Order Form control. This is subject to a current written quote; the Order Form controls. Scoped protection is not universal topic exclusivity.

Measurement and attribution: Measure excessive-access findings, prohibited-action test success, approval cycle time, stale accounts, temporary-access expiry, access-review completion, and safe activations. Permissions enable governance; they do not prove revenue causality.

Proof: Request a live role demonstration, entitlement matrix, two-client negative test, credential and link behavior, export controls, and written scope. Verify the intended complete white-label agency sales-and-delivery engine component by component; public evidence supports conditional portal, client-account, report, filter, and workflow scope, not unqualified completeness.

Meaningful limitation: Reviewed public sources do not document granular BrandWell RBAC, a complete permission matrix, multi-client audit logs, or all required client-separation controls. A buyer needing them today must make them acceptance conditions and choose a different design if they cannot be demonstrated.

2. 6sense

Intended audience and use case: Evaluate 6sense for enterprise revenue teams that need account intelligence and orchestration within a broad go-to-market platform.

Signal/data coverage and freshness: Determine which roles can see first-party activity, third-party signals, scores, contacts, and historical evidence. Test sensitive fields separately.

Identity resolution and validation: Ask who can modify mappings, confidence rules, or contact activation and whether overrides require review.

Integrations and activation: Demonstrate permissions for CRM, marketing, advertising, exports, API credentials, and administration – not only dashboard views.

Implementation effort: Enterprise role design may span marketing, sales, RevOps, IT, privacy, and agency users. Include identity-provider and group-management work.

Privacy and governance: Verify current role documentation, tenant model, authentication options, support access, retention, and party responsibilities for the licensed configuration.

Verified pricing and total cost: Obtain a current quote including required editions, users, modules, implementation, identity administration, and services. No approved evidence supports an assumed public price or annual term.

Measurement and attribution: Track denied-action tests, access-review findings, activation approvals, operator workload, and downstream outcomes independently.

Proof: Require a role matrix, live negative tests, client references with comparable access needs, current security materials, and contractual entitlements.

Meaningful limitation: An enterprise internal-team permission model may not map cleanly to an agency that must isolate many unrelated end clients and preserve its own branded delivery layer.

3. Demandbase

Intended audience and use case: Evaluate Demandbase for mature account-based marketing programs coordinating data, advertising, and revenue workflows.

Signal/data coverage and freshness: Test which users can view account activity, advertising data, contact detail, scoring context, and exports in the proposed modules.

Identity resolution and validation: Restrict account remapping, identity settings, and sensitive data views to named roles; verify behavior with edge cases.

Integrations and activation: Check separate permissions for audience creation, ad activation, CRM sync, exports, configuration, and credential management.

Implementation effort: Role mapping can be significant when agency and client teams share campaign, data, and platform responsibilities. Include ongoing change administration.

Privacy and governance: Verify tenant boundaries, authentication, role controls, support access, regions, and current contractual responsibilities for the deployment.

Verified pricing and total cost: Request a scope-matched quote for modules, users, media, implementation, administration, and services. Do not rely on unsupported market ranges.

Measurement and attribution: Measure access defects, approval friction, prevented errors, activation quality, and client outcomes rather than login counts alone.

Proof: Ask for two-workspace demonstrations, a current permission catalog, security evidence, and reference calls that match the operating model.

Meaningful limitation: A sophisticated ABM platform can be more operationally complex than a reseller needs and may not provide the exact agency/client role hierarchy or white-label experience required.

4. Factors.ai

Intended audience and use case: Evaluate Factors.ai when first-party website identification, analytics, and activation are central and client teams need controlled access to those outputs.

Signal/data coverage and freshness: Determine who can view raw events, company identification, person-level fields, segments, and reports. Treat first-party and enriched fields differently.

Identity resolution and validation: Limit who can alter mapping or validation settings and who can promote a candidate identity into activation.

Integrations and activation: Test permissions for CRM, advertising, messaging, export, pixel configuration, API keys, and automation – not only analytics access.

Implementation effort: Each client may require instrumentation, consent settings, domain mapping, destinations, and user administration. Account for that recurring work.

Privacy and governance: Review role scope alongside notice, consent where required, deletion, provider access, and regional controls with qualified reviewers.

Verified pricing and total cost: Obtain a current quote that includes identification volume, users, destinations, implementation, and administration. Avoid unverified third-party price claims.

Measurement and attribution: Track match-review access, denied exports, activation approvals, configuration changes, and downstream outcomes separately.

Proof: Require a current role demonstration, two-client isolation tests, sample export control, privacy materials, and a documented support-access process.

Meaningful limitation: A platform strong in first-party analytics may not provide broad offsite intent coverage or the exact multi-client white-label role system an agency needs.

5. ZoomInfo

Intended audience and use case: Evaluate ZoomInfo when a buyer wants sales intelligence and related data and activation workflows across a larger go-to-market stack.

Signal/data coverage and freshness: Verify role access to contacts, companies, intent, exports, credits, lists, and administrative data under the proposed package.

Identity resolution and validation: Test who can correct, suppress, export, and activate identity records and whether data-quality overrides are governed.

Integrations and activation: Demonstrate privileges for CRM and engagement syncs, audiences, exports, API credentials, user administration, and destructive actions.

Implementation effort: Include seat and credit governance, client separation, field mapping, user lifecycle, credentials, and support – not just initial configuration.

Privacy and governance: Review current access controls, regional settings, notices, permitted uses, deletion and suppression, and administrative support access.

Verified pricing and total cost: Require a current quote for modules, users, usage or credits, implementation, services, and governance work. Approved evidence does not establish a blanket competitor price or term.

Measurement and attribution: Measure permission defects, inappropriate export prevention, approved activations, valid records, and revenue stages without attributing revenue to access controls alone.

Proof: Ask for a live role and negative-action demonstration, current documents, reference checks, and written entitlement confirmation.

Meaningful limitation: A broad data platform may have access controls for its direct customers but still not deliver the agency-owned client hierarchy, branding, and commercial model required by a reseller.

Build, resell, refer, or avoid the permission layer

Build when the agency has engineering, identity, security, and support capacity and client permissions are central to the product. Custom software creates a durable obligation to test every endpoint, export, automation, cache, support tool, and browser path.

Resell when a provider can demonstrate the required client hierarchy, negative permissions, temporary access, and administration. The agency should own its role design and reviews even if the platform enforces them.

Refer when the client needs direct enterprise identity integration, regulatory controls, or administration the agency cannot safely operate. Retain strategy and activation work without taking inappropriate platform responsibility.

Avoid offering a portal to clients that demand shared credentials, cross-client visibility, unrestricted bulk export, unreviewed automation, or an unsupported granular-RBAC promise.

Package, price, and measure the recurring service

Price the setup from number of clients, users, roles, data classes, destinations, authentication requirements, and approval paths. Recurring work includes onboarding, change requests, temporary access, quarterly reviews, offboarding, credential rotation, negative tests, and exception resolution. Model actual operator time and vendor cost before stating a gross margin.

A recurring package can include a maintained role-permission matrix, least-privilege defaults, monthly joiner/mover/leaver processing, client-admin support, quarterly access certification, temporary-access review, credential inventory, two-workspace negative test, and annual permission redesign. Keep software licensing, implementation, support, and managed governance visible.

Useful KPIs include percentage of accounts with an owner, privileged-user count, stale-account rate, temporary access past expiry, review completion, denied-action test pass rate, approval turnaround, excessive-access findings, offboarding completion, and unauthorized or duplicate activation. Connect these to preserved client trust, reduced rework, accepted activations, opportunity progression, and renewal evidence, but do not claim access controls caused pipeline.

Best-fit clients have several stakeholders, sensitive person-level records, multiple activation destinations, procurement requirements, distributed teams, or frequent staffing change. A single-user client receiving a read-only report may need a much simpler design. Exclude clients unwilling to name administrators, enforce individual accounts, or accept approval boundaries.

Before accepting a platform, keep a small library of permission implementation examples. Include an analyst who can filter but not export, an activator who can prepare but not approve, an agency specialist with one-client temporary access, and a service account that can write only approved fields to one destination. Run the examples after every material configuration or integration change. This operational checklist catches permission drift that a static planning guide will miss. It also gives client administrators a concrete decision guide when a new employee requests “the same access as my manager,” a phrase that should trigger clarification rather than a copied role.

A strong client-level-permissions-in-agency-intent-portals strategy is testable and restrained: define actions first, deny by default, separate preparation from approval, narrow every client scope, expire temporary access, and prove prohibited paths before trusting the portal with live data.

Test a BrandWell agency intent report with the smallest safe role set before expanding client access.