Fields, Sync, and Permissions Reference

Every GW field behaves like a native Salesforce field, and that is the whole point of this reference. Because scores, tiers, segments, Tags, and list memberships are real fields on Lead, Contact, and Account, your existing list views, reports, dashboards, Flows, and permission sets act on them with no new tool and no integration to build, which is what turns intelligence into automation instead of a dashboard nobody opens. Two design choices make it safe to point at your entire database: SignalRx writes to blank GW fields only and never overwrites a human edit, and it honors your field-level security and sharing throughout, running as a scoped integration user that can touch only what you grant it. What follows is every field, the write model, and the governance in full.

Every field SignalRx installs, what each one holds, and how teams normally use it. Then how SignalRx operates inside your org: the write model, the poll cycle, the GW History object, permission sets, and the packaged automations.

01 · How SignalRx writes to Salesforce

• Namespace. Everything installs under the GoodWork namespace. Salesforce prepends GoodWork__ to every API name, so the field labelled GW Contact Score has the API name GoodWork__GW_Contact_Score__c. GW fields never collide with your own or with another package.
• Blank fields only. SignalRx writes to blank GW fields and never overwrites a value a person has entered. Every action has a status field and a last-updated field that SignalRx reads before acting, so a re-poll never clobbers a human edit. This is what makes it safe to point the integration at your entire database.
• Poll cycle. SignalRx polls Salesforce roughly every 20 minutes. On each cycle it reads new and updated records, matches every Lead to a company, deduplicates uploaded lists against your CRM, picks up action requests, and writes results back. Batching keeps the integration inside API and governor limits and produces predictable, auditable updates.
• Refresh cadence. Intelligence fields (scores, segments, tags, list memberships) refresh on a recurring cadence as SignalRx re-evaluates records against your data. A record is current before a rep opens it.
• Standard fields. SignalRx writes to standard fields only when it creates a new Lead, Contact, or Account on your behalf from an uploaded list, and only up to the duplicate threshold you set.

02 · Contact fields

Also installed on Lead.

03 · Account fields

Also installed on Lead, because a Lead has no related Account and SignalRx resolves the company for every Lead.

04 · Action, status, and system fields

Normal practice. Reps set action fields from the Intelligence Card. Flows set them in bulk. Nobody edits intelligence fields by hand; if a value looks wrong, tell your SignalRx team and they correct the model, not the record.

05 · GW History: reporting on movement over time

The package includes a GoodWork History object (GoodWork__GW_History__c). Each time SignalRx changes a tracked GW field it writes a row: the related Account or Contact, the field that changed, the old value, the new value, the change type (for example Score Increase, Score Decrease, Tag Added, List Joined), and the timestamp. A packaged report type joins History to Account.

This is what makes trend questions answerable: which customers lost Health this month, how many accounts moved into High Fit after a model update, how big is the Call Now list week over week.

Things to know before building reports

• Old and New Value are text. They hold whatever the field held, including picklist values and tag names, so they cannot be summed. Add your own formula fields on GW History that cast them to numbers (Score Old, Score New, Score Delta), and a text formula that buckets the changed field into Company Health, Company Fit, and Contact Fit. Your SignalRx team supplies these as a small deployable package.
• Fields you add to a managed object get no field-level security by default, not even for System Administrator. Ship a permission set that grants read on GW History and on your formula fields, and assign it, or every report fails with "no such column".
• A Health score can be cleared rather than decremented when an account leaves the scored population (for example it is no longer a current customer with revenue data). On those rows New Value is blank, so measure the old score that was erased rather than a delta.
• Group on the account's own fields carefully. The packaged report type does not expose every Account custom field. Pull Account Name and Company Segment onto the History row with formula fields so reports group on base-object columns.
• Early on, group by day or week. Monthly grouping with a few weeks of history renders as one bar.

See the capability guide Leadership View: Fit and Health Movement Dashboard for a worked build.

06 · Permissions and governance

Access follows Salesforce's recommended model for managed packages: permission sets, not profiles.

• SignalRx User. Read on all GW fields. Read and write on the five action fields (GW Enroll, GW Find Email, GW Find Phone Number, GW Monitor, GW Company Monitor). Assign to every rep and CSM.
• SignalRx Admin. Everything in SignalRx User plus control of the packaged automations.
• Integration user. Scoped by permission set to the GW fields, the Lead, Contact, and Account objects, and the ability to create the standard records SignalRx generates. Nothing else.

Write access to action fields can be narrowed for specific profiles through field-level security. When a user lacks permission, the Intelligence Card shows the action locked with a reason rather than failing.

SignalRx honors field-level security and sharing throughout. Any GW field is reportable and usable in list views, reports, and dashboards.

07 · Automations

Two ways to run an action. Manually, from the Intelligence Card button or by setting the field on one record. Automatically, when a Flow sets the same field in bulk on every record matching your criteria. Card buttons are wired to the same flows, so a click runs exactly what a Flow would.

Design rules that keep automations safe

• Trigger on updated to meet the condition, not on every save, so a play fires once on entry.
• Use contains on the list membership fields. They are multi-select and hold several play names at once.
• Record the enrollment (a date field or a Campaign membership) so re-evaluation never re-enrolls a past cohort.
• Review the first run of every list by hand before anything sends. First runs are usually wrong somewhere.

08 · Administrator FAQ

Storage and API footprint?

The GW fields listed above plus the GW History object. Reads and writes run on a roughly 20-minute cycle inside API and governor limits. Packaged automation runs under the package's own governor limits.

Duplicates?

Every Lead is matched to a company, and uploads are deduplicated against Salesforce before anything is created. You set the creation threshold. SignalRx respects your duplicate rules.

Validation rules and triggers?

SignalRx writes as the integration user. Exclude that user from rules that would block legitimate writes.

Uninstall?

Salesforce offers to save a copy of the package's data for 48 hours. GW fields and objects, and the data in them, are removed with the package. Values SignalRx wrote to standard fields when creating records remain.

Picklist values?

Segment, tier, and classification values are configured to your business and maintained by SignalRx through package upgrades.

Person accounts, record types, custom objects?

Supported. Mapped during onboarding.

Backup and rollback?

Writes are non-destructive. A standard backup before install is still good practice.

Versions?

The installed version shows in Setup → Installed Packages. New versions ship with release notes and apply without disrupting data or configuration.