How to let customers create custom views without handing over the product.
To let customers create custom views safely, start with one dashboard and define what is shapeable: fields, filters, grouping, sorting, summaries, and saved-view scope. Keep permissions, private fields, data access, billing, destructive actions, and workflow rules locked. Customers can then create views inside those boundaries without every request becoming engineering work.
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 one dashboard generating repeated custom-view requests
- SaaS builders separating view changes from product changes
- teams that need personal or team saved views
- product teams trying to reduce support-built reports
Not a fit:
- requests mostly about permissions, billing, or workflow behavior
- blank-canvas BI exploration
- surfaces without a clear safe data set
- teams without a live dashboard to test
Step 1: Pick one surface
Do not start with every dashboard. Pick one surface where customers already ask for view changes.
The right first surface has repeated requests around columns, filters, grouping, sorting, saved views, or defaults.
Step 2: Separate view changes from product changes
A custom view should change how safe data is arranged. It should not change the product itself.
- view changes: columns, filters, grouping, sorting, saved views, defaults, summaries
- product changes: permissions, billing behavior, workflow rules, integrations, destructive actions
Step 3: Define the shapeable surface
Before customers create anything, define the allowed surface. This contract matters more than the interface.
- which fields can appear and which stay hidden
- which filters, groupings, and summaries are allowed
- which actions are locked
- whether views are personal, team-wide, or admin-wide
Step 4: Make the first view request concrete
Do not start with: let users customize everything. Start with a real request like: let account managers save a view of enterprise renewals grouped by CSM, sorted by renewal date, with trial accounts hidden.
That gives you something testable and forces the boundary decisions before the UI grows.
Step 5: Track whether requests stop returning
Custom views are not the goal by themselves. The goal is fewer repeated requests.
Track custom views created, first-shape completion, view saves, dashboard feature requests before and after, and requests that hit a locked boundary.
Keep reading
Use these live pages to compare adjacent ShapeKit patterns without landing on a missing route.
Test custom views on one dashboard.
Bring one surface where customers already ask for custom views and where your team can define safe fields and locked rules.
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
How do customers create custom views safely?
They create views inside a shapeable surface that the developer defines first. Safe fields, filters, grouping, summaries, and saved-view scope are allowed; product-owned rules remain locked.
Should custom views be personal or shared?
Start narrow with personal or team views. Tenant-wide or admin-wide defaults affect more users and need stronger governance.
What is the first implementation step?
Pick one live dashboard or table, list safe and locked fields, and implement one concrete saved-view request.