Let users customize their dashboard without handing them the keys.
You can let users customize their dashboard safely by separating the parts they can change from the parts only your product controls. Users should shape columns, filters, grouping, sorting, and saved views. Developers should keep ownership of permissions, data access, business logic, and internal fields.
ShapeKit is built for the middle ground: your product defines the safe boundary, and users shape their own view inside it.
Who this is for
Good fit:
- teams with multi-tenant dashboards
- teams whose customers ask for different default views
- teams debating build-vs-buy for dashboard personalization
- teams that want user control without a full builder
Not a fit:
- dashboards where every customer needs a different data model
- workflows where users should not change the view
- pure BI use cases where analysts already own the dashboard layer
- cosmetic customization only
What parts of a dashboard should users customize?
Start with view changes. These are the requests that usually sound like: can I see this by region, can our account managers hide these columns, or can this be my team's default view?
Those requests should not need a sprint when the data and permissions are already safe.
- visible columns and column order
- filters, grouping, and sorting
- saved views and team defaults
- simple summaries, density, and focus controls
What parts should stay controlled by the product?
Keep the product-owned parts out of user customization. If changing it can break trust, expose private data, or alter product behavior, it is not a user-owned view setting.
- permissions and data access
- internal-only fields and audit trails
- workflow, billing, integration, and validation rules
- destructive or system-level actions
How does ShapeKit let users customize dashboard views?
ShapeKit starts with the Crafter. The Crafter defines allowed fields, safe filters, valid groupings, summaries, actions, and default constraints.
Then the Shaper asks for the view they need, such as: show high-priority accounts by renewal date, hide accounts under $10k ARR, and save this for my team.
ShapeKit turns that into a user-owned dashboard view without changing the underlying app.
How should you roll this out?
Do not start with every dashboard. Start with one surface where view requests are frequent and safe.
Good first surfaces include an account list, customer health dashboard, ticket queue, admin table, sales pipeline, or reporting view.
Keep reading
Use these live pages to compare adjacent ShapeKit patterns without landing on a missing route.
Want to let users shape one dashboard?
We are looking for teams with a real dashboard where users already ask for different views. Bring one dashboard, not a theoretical roadmap item.
Good test workflow:
- one live SaaS dashboard, admin panel, table, or reporting view
- repeated requests around columns, filters, grouping, sorting, or saved views
- a clear first pass at safe fields and locked fields
- one user group that can test shaped views within 14 days
This is not a generic demo request. Tell us about the dashboard where requests keep hitting engineering, support, or client services.
Frequently asked questions
What is the safest way to let users customize dashboards?
The safest way is to define a shapeable surface first. Users can change columns, filters, grouping, sorting, and saved views while permissions, private fields, and product behavior stay locked.
Should users be able to customize everything?
No. SaaS users usually need different views of the same safe data, not control over permissions, billing, workflow logic, or internal fields.
What should a team test first?
Start with one live dashboard or table that already generates repeated view-change requests and has a clear safe field list.