How to use a Righthand with Little Green Light

Quick answer

Use Righthand to prepare a Little Green Light stewardship checklist from a scoped donor export. Organize follow-up evidence while preserving the system's accepted constituent records.

Start with a reviewable deliverable, keeping Little Green Light 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

Little Green Light describes donor management and connected tools on its official site. See the official Little Green Light reference. Provider capabilities and Righthand's available tools are separate checks.

Request the owner's limited constituent and gift packet, campaign definitions, cutoff, and allowed contact fields rather than an unrestricted database export. 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: constituent ID, gift ID, fund, date, acknowledgment field, contact preference, staff owner. These are the requested review columns, not a promise that every provider endpoint returns them under those exact names.

Keep contact preferences and restricted details intact. Staff approve correspondence, record changes, and gift classification.

Illustrative first-run brief

Use the owner-provided Little Green Light snapshot or approved read-only view. Review one month's approved gift snapshot. Identify missing acknowledgment evidence and unassigned stewardship tasks. Prepare internal proposals only. 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 donor-services 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 donor with an existing no-contact preference remains excluded from proposed messaging even if a follow-up field is blank.

Compare sample IDs and fund totals with the same source report; retain supplied preference values. 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 repeated donor name can represent distinct people. Use stable identifiers and review relationships rather than merging by name.

If acknowledgment history is missing, ask the fundraising owner for the specific gift record before proposing another acknowledgment.

FAQ

What should the reviewer verify first?

Check constituent and gift IDs, received date, fund designation, and acknowledgment evidence. Similar donor names should never replace stable identifiers.

How should a repeat run be scoped?

Preserve gift IDs, period, and acknowledgment cutoff across runs. Recheck new acknowledgments and contact restrictions so the next review does not duplicate previous work.

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