When to use it
Create a Chapter
Salsa’s Chapters package provides local field organizers with access to Salsa information that has been segmented to their chapter. Chapters can build their own lists, create action pages, donation pages, and send their own email—while at the same time enabling national-level managers to oversee their activities. Chapters cannot see the overall organizational data at the national level - their information is restricted to their chapter.
Chapters serve as a grouping mechanism in Salsa that grants limited access to a segment of an organization’s supporters. Campaign managers in a chapter are enfranchised to see only what other managers in that chapter create and/or what national level managers syndicate to them.National-level campaign managers can set up their chapters using whatever criteria they prefer—by geography, by program type, by issue, etc. In addition, Chapters can be tiered—a chapter can itself have chapters to which it is the parent.
In addition to the Chapters packages, Salsa’s Syndication package allows chapters and national-level campaign managers to create Salsa pages, email blasts, and templates at the national level and share them to chapters.
How to get there
From your dashboard, or when viewing the package list, select Chapter.
Create a Chapter
Suppose Salsa Labs wanted to set up a chaptered organization for the company. Let’s also suppose we have multiple offices in multiple states. In this case, the easiest way to manage chapters would be to have 3 tiers: a national level, a state level, and a local level. The illustration below lays out how we’d like to set up our Salsa account using the Chapters tool.
In this example, there is the national-level—noted as the "Org Level," as well three state-level chapters (Tier 2): Texas, DC, and California. There are also two local-level chapters (Tier 3): Austin and San Francisco.
Chapters essentially share supporter records that are visible to their campaign managers. This has a huge advantage for record-keeping: Rather than have duplicate records for each chapter, supporters exist in multiple chapters at one time.
So in our example, campaign managers at the chapter level (those in Tier 2 or Tier 3) will have access to supporter records that they created, have subscribed to their chapter, or are in a child chapter. Thus, Texas can see every supporter produced both in its own chapter and all of the objects produced in the Austin chapter. Additionally, a campaign manager logged into Salsa Labs at the org-level would see every object in every chapter under that organization. One thing to remember: Because chapters in Salsa can see the same item in Salsa, changing it anywhere means every other place that it’s visible will change, too.
To take a simple example: If Sally is a member of both California and DC (using the chapter layout illustrated above), and Steve, a California chapter administrator, decides to change her email address from firstname.lastname@example.org to email@example.com, that change will be visible to both DC and the organization level. If Steve continues to change her record, say by updating her title to President and CEO, that change, too, will be reflected wherever Sally is a member, namely in the DC chapter and at the organization level.
Now, suppose Steve made the updates above, then Jamie, the chapter admin of the DC chapter, viewed the record the next day. Jamie would see:
- Sally’s new email address, firstname.lastname@example.org
- Sally’s new title, President and CEO
- A Last_Modified date generated by Steve’s operation on Sally’s supporter record.
Jamie would be understandably confused. If she hadn’t touched the record recently, hadn’t made the updates herself, and was the sole chapter administrator of the DC chapter, she wouldn’t know how the information got there.
The same effect can occur in other more complicated cases:
- Suppose two chapters, DC and California, contain supporter Sally. If DC emails Sally and her email address hard bounces, the new hard bounce count will be reflected in both chapters and at the organization level, even if California never emailed Sally at all.
- Suppose Sally signed up with the DC chapter before she signed up with California. Her Source_Details field will always show the DC signup page, even if she spends the rest of her time taking California’s actions
- Suppose Sally unsubscribes “from everything” on an organization level unsubscribe page. Per the description of unsubscribe behavior, below, this act would change her Receive_Email value to -3, meaning the system would never email her no matter where the email was sent in the organization. The chapter admin, Jamie, would never be able to see what caused Sally to unsubscribe, because she wouldn’t have the ability to see data generated by organization level pages.
Yet, while chapters share and can see supporter records, they cannot fully delete a supporter record from the organization. Any supporter “delete” operation processed at the chapter level will remove that supporter from the chapter but will not remove that record from the organization. To permanently remove a supporter from an organization, the delete must occur at the organization level. As a rule of thumb, remember that any deletion that occurs at the organization level will remove the record entirely from that organization and all of its chapters.
Other Salsa Items
Outside of the supporter record, however, all other data is chapter specific. This includes group membership, actions, donations, event registrations, templates, or any other page or item created by a campaign manager at the chapter level. That data is only accessible to the chapter in which the action or donation was taken or given and to the national-level campaign managers.
Additionally, chapter-level pages will have an additional element in public facing page urls to indicate that it is a chapter-level page and to which chapter it belongs:
...where XXX is the key for the chapter in Salsa. For example, a chapter-level donation page may look like the following:
More on deduplicating in chapters can be found here.
Even though the Chapters package allows chapters to essentially share supporter records, sometimes duplicates will make it into the system. Salsa’s built-in deduplicator is an easy way to solve this problem. That said, because the deduplicator will lead to the permanent removal of duplicates only org-level campaign managers can use it.
Chaptered organizations have four types of custom fields.
- Org level only: These are custom fields, left unsyndicated and unexposed (they don’t have the “Expose to all chapters?” box enabled), created at the org level. They are not visible to any chapter. Org level only custom fields store their information in supporter_custom.
- Org level exposed: Custom fields that are exposed to chapters will be visible in all chapters, and just like supporter records mentioned above, any changes to the content in the field will be seen by all chapters/the main organization level.
- Org level syndicated: Custom field syndication creates a copy of the field you syndicate at the chapter level. There are two differences between syndication and exposure. First, syndication allows you to target some chapters, as opposed to all of them, when selecting recipients for the field. Second, the data that is stored in the syndicated copy is unique to each chapter.
- Chapter level custom fields: Chapter level custom fields are stored in the custom_data_* tables, where the wildcard represents the field type. Custom fields generated at the chapter level are only seen by that chapter and none other, including the organization level. This is one of the few exceptions to the visibility rules described above.
Querying custom fields should always occur at the level of interest. If, for example, Steve, our California chapter administrator, wants to query about California’s chapter-specific custom fields, he should query for them within the California chapter. He can’t query about them at the org level or in San Francisco’s.
The subscription status of supporters in Salsa is determined normally by the Receive_Email field (located in their supporter record in the Profile tab). If a supporter’s Receive Email value is less than zero, no email would ever be delivered to his email address, regardless of whether that supporter exists in any chapter or only at the org-level.
However, when an organization has the Chapters package installed a field in a different table (supporter_chapter) will determine whether he/she is subscribed to that specific chapter. That field (unsubscribe) must be set to 0. If a supporter unsubscribes from the chapter (more on how this can be done below), the value in this field is switched to 1. This will prevent Alan from receiving email from that particular chapter, say, chapter San Francisco, but not from California, of which he’s a member, or Salsa Labs itself, the T1 level organization.
Unsubscribe pages are governed by the unsubscribe package, also known as salsa.supporter.unsubscribe. Campaign managers will be able to design custom unsubscribe pages by installing this package. Supporters who unsubscribe from an unsubscribe page generated at the org level will set their Receive_Email status to -3 -- unsubscribe that supporter from the entire organization. While, at the same time, supporters who unsubscribe from a page created at the chapter level will only unsubscribe from that chapter’s emails. If a supporter is a member of both a parent chapter and a child chapter, unsubscribing from the parent is not sufficient to also unsubscribe from the child.