Bought by ops, abandoned by everyone else
When every screen is built for the buyer persona, the rep, the content marketer, and the CMO see a wall of someone else's data. Adoption stalls, and renewals get hard.
Wave · Role-Based Views
Every team member gets the lens built for their job.
The same intelligence, shaped per persona: content marketers, ABM managers, sales, marketing ops, leadership, and IT. Sensitive fields stay hidden from lenses that do not need them, and access is decided server-side, never by the lens.
Wave~
Accounts
People
Buying Groups
Schedule
Content
Insights
Settings
People › Dana Kim
DK
Dana Kim
VP Finance · Meridian Financial Group
Viewing as: Sales
Next themeSecurity certification
Consent detailshidden for this lens
Quick answer
Role-Based Views shape Wave's interface to the job in the seat. Seven named personas ship: a generalist default plus content marketer, ABM manager, sales, marketing ops, leadership, and IT and data. Each persona emphasizes what that role runs on, across accounts, people, buying groups, content, and schedule. Sensitive field classes are withheld server-side from personas that do not need them, and switching a lens in the UI never expands what a seat can access.
Key capabilities
- Seven named personas covering the full revenue team
- Layouts reshape across accounts, people, committees, content, and schedule
- Sensitive field classes withheld server-side, absent from responses
- Lens previews never expand data access
- Admins can verify exactly what any seat sees
- Off by default, so rollout carries zero regression risk
Last updated: July 2026
The problem
One interface for six jobs serves none of them.
Intelligence platforms are bought by one role and expected to be adopted by six. Most become the cluttered tool that only the person who configured it ever opens.
Hiding fields in the UI is not governance
A field hidden with CSS still left the server. For regulated teams, the wrong person being able to fetch the wrong field is an audit finding, whether or not it rendered on screen.
Onboarding by firehose
Training every role on the full platform means most people learn none of it. Each role needs the five things that matter for their job, not a tour of everything.
How Wave does it
One platform, seven lenses, access decided server-side.
Personas change what each seat sees. Permissions still decide what it can do. The two are separate by design, and the separation is enforced where it counts: on the server.
- 01
Assign a persona to each seat
Each seat carries one of seven personas: generalist, content marketer, ABM manager, sales, marketing ops, leadership, or IT and data. The assignment lives with the seat on the server, not as a browser preference.
- 02
Every surface reshapes
Accounts, people, buying groups, content inventory, and schedule reorder per persona. Sales sees seat status and next content; ops sees writeback health and confidence; leadership sees motion trends without operational noise.
- 03
Sensitive fields never leave the server
Classes of sensitive data, consent and compliance signals, raw contact PII, financial fields, model internals, and source record identifiers, are omitted from responses for personas that do not need them. Absent, not hidden: a hostile client cannot recover a withheld field.
- 04
Preview without privilege
A lens switcher lets anyone preview another persona's layout, but the lens is presentation only; field access always follows the seat's assigned persona. Admins can experience any seat exactly as that seat sees it, gating included.
Where it fits
A view layer across everything Wave knows.
Role-Based Views are not a module; they are how the whole platform renders. Every Wave surface inherits the persona system.
Same underlying data
Wave
A lens for every role
Permission tiers keep deciding what a seat can do while personas decide what it sees, so a leadership seat and an ops seat can look at the same account and get materially different, equally true, views. Field gating is enforced once, server-side: the architecture answer to the governance question, not a UI toggle. When an admin impersonates a seat to verify a rollout, they experience that seat's exact gating.
Works alongside The full Wave platform; see Wave's trust posture for the governance model behind field gating.
Why Wave is different
Per-role UX is usually a services project. Wave ships it.
Competing platforms force one view on everyone or quote you a dashboard-building engagement. Wave ships the persona library in the product, with governance built into the architecture.
Most tools
Wave
One view for every user; "role" only means permission level.
Seven named personas shape what each role sees, from the same underlying intelligence.
Per-role dashboards require an engineering or services project.
Personas ship in the product. Assigning one is an operator action, not a build.
Field visibility is handled in the UI, so the data still reaches the client.
Withheld fields are absent from the response itself. Switching lenses never changes what leaves the server.
Admins guess what other roles actually see.
Admins can verify any seat's exact view, field gating included, before rolling anything out.
FAQ
Questions buyers ask about Role-Based Views.
What are Role-Based Views in Wave?
A persona dimension on every seat that shapes what Wave shows: layout, emphasis, and field visibility per role, across accounts, people, buying groups, content, and schedule. Permission tiers still control what a seat can do; personas control what it sees.
Which personas ship with Wave?
Seven: a generalist default that matches the standard layout, plus content marketer, ABM manager, sales, marketing ops, leadership, and IT and data. Each maps to a layout tuned to how that role actually works.
What does each persona emphasize?
Sales gets seat status, deal context, and recommended next content. Content marketers get asset performance and format signals. ABM managers get account coverage and motion views. Marketing ops gets writeback health, cadence, and confidence diagnostics. Leadership gets motion health and portfolio trends. IT and data gets provenance and technical metadata.
What data can a persona not see?
Wave classifies sensitive fields into classes, consent and compliance signals, raw contact PII, financial fields, model internals, and source record identifiers, and withholds each class server-side from personas that do not need it. Withheld fields are absent from the response, not blanked or hidden.
Can switching a lens expose more data?
No. The lens switcher changes presentation only. Field access always follows the seat's server-side persona assignment, so previewing another persona's layout never expands what a seat can retrieve.
Is a persona the same as a permission level?
No, and the separation is deliberate. Permission tiers (admin, operator, viewer) govern what a seat can do; personas govern what it sees. A viewer-tier sales seat and an admin-tier sales seat see the same sales-shaped layout with different abilities.
How do we roll it out safely?
The feature is off by default per tenant. When off, every seat renders Wave's standard layout, unchanged. Turn it on when your team is ready and assign personas seat by seat; a global emergency stop sits above the per-tenant switch.
How do I see it for my team?
Book a 20-minute walkthrough. We will show the same account through a sales lens and an ops lens side by side, including how field gating differs between them.
See it on your team
Show every role their version of Wave.
Book a 20-minute walkthrough. Bring a rep, a content marketer, or your ops lead, and we will show each of them the lens built for their job.
Request a demo