How to use a Righthand with GoCanvas

Quick answer

Use Righthand to prepare a GoCanvas submission exception review. Keep form versions and attachment evidence together so missing fields are not confused with changed questions.

Start with a reviewable deliverable, keeping GoCanvas 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

GoCanvas's help center documents form-building, reference-data, and workflow topics. See the official GoCanvas reference. Provider capabilities and Righthand's available tools are separate checks.

Use the owner's approved form submissions and schema version, with submission IDs, required fields, and acceptance rules. 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: form name, version, submission ID, submitted time, required field, attachment, reviewer. These are the requested review columns, not a promise that every provider endpoint returns them under those exact names.

A collected response is not validated evidence by itself. Keep technical acceptance and any signed approval with the responsible supervisor.

Illustrative first-run brief

Use the owner-provided GoCanvas snapshot or approved read-only view. Review twenty approved inspection submissions against the current checklist. Flag absent required responses and missing attachment references. Do not alter submissions or sign records. 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 operations supervisor 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 photo reference is a request for evidence, not proof the inspection was never performed.

Compare a flagged submission with the form version used at submission time. 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

A revised form can make old records appear incomplete. Apply the correct historical version and report unresolved version mapping.

If the form changed during the period, separate submissions by version and ask the process owner which requirement set applies.

FAQ

What should the reviewer verify first?

Check submission ID, form version, required fields, attachments, and reviewer state. A submitted form can still be incomplete under the owner's acceptance rules.

How should a repeat run be scoped?

Keep form version and submission window explicit on each run. Reevaluate only changed or unresolved records; do not impose a newer schema retroactively without owner instructions.

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