How to use a Righthand with Supabase

Quick answer

Use Righthand to prepare a Supabase data-quality review using an approved table sample. Account role and row visibility are part of the evidence, not details to hide.

Start with a reviewable deliverable, keeping Supabase as the accepted home for its records. This guide uses an explicitly approved snapshot or browser read; it does not assume that every provider API action is exposed by your Righthand connection.

Evidence and access

Supabase documents its data REST API and PostgreSQL row-level security model. See the official Supabase reference. Provider capabilities and Righthand's available tools are separate checks.

Use the approved project's read-only inventory and owner-provided query or schema results, with project identity, environment, and cutoff. Verify the required tools and owner-approved scope through Righthand integrations; use the supplied packet when a native read is unavailable.

Define the objects and authority

Include these fields in the working input: project, schema, table, primary key, selected columns, filter, role, snapshot time. These are the requested review columns, not a promise that every provider endpoint returns them under those exact names.

A permitted role may see only some rows. Keep schema changes, policy changes, and customer-record writes outside the first run.

Illustrative first-run brief

Use the owner-provided Supabase snapshot or approved read-only view. Review the supplied support-request sample for missing owners and inconsistent statuses. Return record-specific questions without updating tables or policies. Run once for the agreed sample, using America/Los_Angeles for the review deadline and preserving source timestamps separately. Return the draft in this conversation by Friday at 3 PM Pacific for the data owner to review. Include source references and missing fields. Do not write records, spend money, change permissions, or send external messages. Stop and report an unavailable source rather than substituting another account.

Expected result and verification

A missing row can mean outside the sample or hidden by policy, not necessarily deleted. The report identifies the known visibility boundary.

Reconcile sample keys and count with the same approved query, role, and filters. Record the source cutoff, applied filters, and items excluded from the sample. The reviewer should be able to follow each consequential finding back to an original object. A well-written summary is not evidence that a proposed action happened. If a later write is authorized, verify its specific result separately before changing the task's status.

Illustrative input and draft output

These synthetic entries show the requested review, not live account results or a provider field schema.

Common failure and recovery

Using an administrative view can expose more than the task needs. Recover by reducing columns and restoring the approved role before repeating the read.

If a query result lacks its filters or environment, ask for the exact read context before comparing rows. Do not rerun an unrestricted query.

FAQ

What should the reviewer verify first?

Verify project, schema, table, query scope, and timestamp. An empty result means no rows matched that read, not necessarily that the underlying data is absent.

How should a repeat run be scoped?

Preserve project and filter definitions across reviews. Recheck affected rows after an authorized correction and keep schema changes or migrations outside this reporting task.

For connection and permission details, use Righthand Docs. Review Pricing alongside any separate provider charges before expanding the workflow.