Review requests

Review requests give people who build in their personal space a built-in path to share their work. Instead of DMing someone with edit access or circulating links to personal-space content, a user submits their chart or dashboard for review. A reviewer checks it, and on approval the content moves into a shared space — optionally picking up a verified badge at the same time. This closes the loop on personal spaces: create → request review → approve → promote and verify.

​

Requesting a review

Anyone with content in their personal space can request a review:

1. Open the chart or dashboard in your personal space
2. Choose Request review from the … menu (also available from the content’s row in listings)
3. Pick the shared space the content should move into. The target must be a shared space in the same project, and you need at least view access to it.
4. Add a note for reviewers — what it shows, and who it’s for
5. Submit the request

Each chart or dashboard can have one pending request at a time. While a request is pending, the content shows a Review pending badge, and you can cancel the request yourself and resubmit later.

​

Similar content is flagged before you submit

When you pick a target space, Lightdash checks whether similar content already exists in the project’s shared spaces and shows you the matches — verified matches first — before you submit. If the dashboard that answers your question already exists, you’ll find it here instead of shipping a duplicate. Reviewers see the same matches next to the request, so duplicates get caught even if the requester submits anyway.

​

Reviewing a request

Reviewers find pending requests under Browse → Review requests, and get notified when a new request comes in — in Lightdash, and in Slack if your organization has the Slack integration set up. Reviewers get temporary access to the content while the request is pending, so they can open the chart, check the numbers and the name, and then decide:

• Approve and move moves the content into the target space, where everyone with access to that space can find it. Tick Verify on approve to add the verified badge as part of the same step — it ranks the content first for Ask AI and search, exactly as if you’d verified it by hand.
• Reject keeps the content in the requester’s personal space. The requester sees your note and can ask again after making changes.

Every request keeps its history — who asked, who decided, and when — so there’s an audit trail for how content became shared or verified.

​

Who reviews requests

By default, a request is routed to whoever can edit the target space — its editors and admins, excluding the requester themselves. To route all requests to a fixed set of people instead, open Review settings on the Review requests page and choose a reviewer group. When a group is set, its members review every request regardless of target space. The group needs access to the project. Either way, approving requires edit access to the target space, since approval moves content into it.

​

Review requests and verified content

Verify on approve is the bridge between review requests and verified content. Teams that use verification as their trust signal can make review the only road to it: users build freely in their personal spaces, and everything that reaches shared spaces has been looked at — and badged — by a reviewer. To keep verified content locked down after promotion, pair this with the Edit or delete verified charts and dashboards (manage:VerifiedContent) scope on custom roles, so promoted-and-verified content can’t be edited by the general editor population.