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.

Test custom views on one dashboard See constrained customization

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.

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.