MobilizeAmerica has two sync styles for the ActionKit integration — which operate independently of one another and can be enabled separately. The first is the  “CRM” style integration, which syncs shift- and volunteer-level data from Mobilize to ActionKit, and second is the “distributed send” style integration, which syncs all owned and promoted events from Mobilize to ActionKit.

Each integration makes use of a single separate ActionKit event campaign, and uses one or more ActionKit pages within each event campaign to create the relevant data.

To set up each integration, organizations will need to provide:

  • The base url of their ActionKit instance, e.g. https://roboticdogs.actionkit.com/
  • An ActionKit username and password to authenticate API requests
  • For the CRM style event campaign, you’ll need to provide:
  • The event create page short name
  • The signup create page short name
  • For the Distributed Send event campaign, you’ll need to provide:
  • The event create page short name

Integration details

CRM

Intended for shift and person-level data.

Data synced

  1. Mobilize attendance → ActionKit EventSignup
  2. Mobilize person → ActionKit User
  3. Mobilize dashboard user → ActionKit User
  4. Mobilize event timeslots → ActionKit Event
  5. All owned events, and promoted events to which you’ve driven signups
  6. If a Mobilize event has 2+ shift times, we create a new ActionKit event per shift time

Masking

Some event and shift-level data can be hidden because of the Independent Expenditure/Coordinated firewall. 

Masking is applied when you promote an organization across the firewall in Mobilize, and it works in the following way:

  • For signups that you recruit to the promoted event, we will create a masked representation of that promoted event in ActionKit and sync masked representations of the signups to that event. Details that remain preserved on the event model are time and event type. Details that remain preserved on the signup model are first name, last name, phone number, email. 

Masking is also applied when an organization across the firewall promotes your organization, and it works in the following way:

  • Signups that are sent to the event from the promoting organization have all details preserved except we mask which organization recruited the signup (by masking the mobilize_signup_source field)

Distributed send

Intended for email programs pushing out events to supporters.

This should use a separate event campaign in ActionKit from the CRM integration, if enabled.

Data synced

  1. Mobilize event timeslots → ActionKit Event
  2. All owned and promoted events
  3. If a Mobilize event has 2+ shift times, we create a new ActionKit event per shift time

Masking

We don’t apply any IE/Coordinated firewall masking in this case, since no signup-level data is synced.

Data

The data synced in each integration is largely similar to what we provide in our API, except converted to relevant ActionKit fields. Documentation on what we provide via the API is available here: https://github.com/mobilizeamerica/api.

For example, the event summary in the Mobilize API gets written to an ActionKit event as its public_description.

A full mapping is available upon request.

Custom behavior

To account for behavior around syncing certain Mobilize data that don’t have first-class representations in ActionKit, we will be syncing them with the following behavior:

  • Mobilize Virtual Events
  • We will set those locations to these events in the US Virgin Islands, 00840
  • Masked events and signups
  • For firewall-ed data, certain fields will be given the value ‘Masked’, to prevent coordination
  • Location fields will be set to the US Virgin Islands, 00840 

Custom fields

We create custom fields on ActionKit events for concepts that exist in Mobilize but not in ActionKit.

For example, the name of the organization that drove a signup (sponsor.name in the Mobilize API) is written to ActionKit EventSignups in the custom field mobilize_signup_source.

Since ActionKit requires that the type of these custom field values be string, where a field holds boolean data, a true boolean value will be written as "Yes" and a false boolean value will be written as "No".

Dictionary of custom fields for Event Model

Did this answer your question?