Using SignalRx Natively in Salesforce

You do not have to open SignalRx to use it. SignalRx does its work in the background and hands the results to Salesforce as ordinary fields on Lead, Contact, and Account. Reps read them on the record, managers report on them, and admins automate on them, all with standard Salesforce tools. This guide walks through the day-to-day: how to read a record, work a list, automate on it, ask SignalRx for something from inside Salesforce, and see what changed.

How SignalRx shows up in Salesforce

SignalRx installs as a managed package under the GoodWork namespace, so Salesforce prepends GoodWork__ to every API name and every field label starts with GW. It writes only to blank GW fields and never overwrites a value a person entered, which is what makes it safe to point at your whole database. It polls Salesforce roughly every twenty minutes, so a record is current before a rep opens it, and GW Last Updated tells you when it was last touched.

SignalRx touches standard fields in exactly two situations. When it creates a new Lead, Contact, or Account from an uploaded list, and when one of the packaged Data Hygiene Flows copies a sourced value into a standard field that is blank. Everything else stays in GW fields.

Read a record

GW fields are installed on Lead, Contact, and Account and sit in a GoodWork Information section on the Details tab. Lead gets both the contact-level and company-level fields, because a Lead has no related Account and SignalRx resolves the company itself.

The fastest way to make all of this legible is the SignalRx Intelligence Card, added to your Lead, Contact, and Account record pages in Lightning App Builder. Its Summary tab shows the Fit score and tier, buyer segment, a short description, firmographics, and Tags in one panel. The Details tab lists the full field set, and the Plays tab lists the Revenue Plays the record is in, so a rep sees the same picture the app shows without leaving Salesforce. The card also carries Source Email Address and Source Phone Number buttons.

Work a list

Every Revenue Play and every uploaded list publishes its name into GW Contact List Memberships (Contact and Lead) or GW Company List Memberships (Account and Lead). Those two fields are the handle for everything below. They are multi-select, so a record can be in several plays at once, and a value drops off on its own when the record stops qualifying.

A rep works a play from a list view, and it takes a minute to build.

1. Open the Contacts, Leads, or Accounts tab and create a new list view.
2. Add a filter on the membership field with the operator contains and the play name as the value. Use contains, never equals, because the field holds several names at once.
3. Add GW Contact Score or GW Company Health Score as a column and sort on it, so the list is worked in priority order.
4. Share the view with the team that owns the play.

The same filter works anywhere Salesforce accepts one. A report grouped by GW Company Health Tier or GW Company ICP Fit Tier gives a manager the shape of the book. A Campaign can be populated from a report or a Flow keyed on membership. A dashboard component on a membership report shows a play's size over time.

Automate on membership

Because membership is a field, it is also a Flow trigger, and this is where most of the value is. The pattern is always the same: a record-triggered Flow that runs when a record is updated to meet the condition, with the membership field contains your play name. Then do the obvious thing: add to a Campaign, enroll in a sequence, create a Task, or reassign the owner. Three rules keep it safe.

• Use contains, never equals. The field holds several play names at once.
• Trigger on entry, not on every save, so a play fires once per record rather than on every poll.
• Record the enrollment with a date field or Campaign membership, so re-evaluation never re-enrolls a cohort you already worked.

The capability guides are complete builds on this pattern: an always-on nurture in Win Back Lost Deals with an Always-On Nurture, an outbound motion in Cross-Sell at Day 30 with an Outbound Sequence, and health-driven alerting in Catch At-Risk Customers the Day They Turn.

Ask SignalRx for something from Salesforce

Action fields run the other direction: your team sets them, SignalRx reads them. GW Enroll sends a record to be researched, scored, segmented, and tagged. GW Find Email and GW Find Phone Number source missing contact details. Set them to Yes on one record from the Intelligence Card, or in bulk from a Flow or a list view; SignalRx picks them up on the next poll, writes the result into the GW fields, and resets the action field to No.

Enrollment is the one to remember. A rep who creates a Lead by hand, or an admin who imports a batch, can enroll those records without leaving Salesforce, and they are scored and tagged within a cycle or two.

See what changed

The package also installs a GoodWork History object. Every time SignalRx changes a tracked GW field it writes a row: the related Account or Contact, the field, the old value, the new value, the change type (score increase, score decrease, tag added, list joined) and a timestamp. A packaged report type joins History to Account.

This is what turns point-in-time scores into trends. Which customers lost Health this month. How many accounts moved into High Fit after a model update. Whether the at-risk list is growing or shrinking week over week.

Two things to know before you build a report on it. Old Value and New Value are text fields, so they cannot be summed. Add your own formula fields to cast them to numbers and to bucket the changed field into Company Health, Company Fit, and Contact Fit. And fields you add to a managed object get no field-level security by default, not even for System Administrator, so ship a permission set granting read on GW History and your formula fields or every report fails with "no such column".

Who can see what

Access follows Salesforce's recommended model for managed packages: permission sets, not profiles. SignalRx User gives reps and CSMs read on all GW fields and write on the action fields. SignalRx Admin adds control of the packaged automations. The integration user is scoped to the GW fields, the three objects, and the records SignalRx creates, and nothing else. SignalRx honours field-level security and sharing throughout, and every GW field is reportable and usable in list views like any other.

One practical note: SignalRx writes as the integration user, so if a validation or duplicate rule would block a legitimate write, exclude that user from the rule. This is the standard pattern for integration accounts.

Where to go next

• Getting Started with SignalRx for Salesforce: installing the package, the service account and its permissions, adding the Intelligence Card to your record pages, and which capability guide to read next.
• Fields, Sync, and Permissions Reference: every GW field by object with type and typical use, the packaged Flow templates, GW History in detail, permissions, and the admin FAQ.