Platform

Updates / Bug Fixes

• We've added daisy_chain_rules, daisy_chain_steps, and daisy_chains to our bulk data API. This will allow organizations to get data on how campaigns are configured to behave after members take action and do analysis on post signing experiences. More information is available: https://developers.controlshiftlabs.com/#bulk-data-data-schemas.
  
  
• We've made updates to the blast emails details page for admins to improve performance. 
  
  
• We've improved the performance of resilience of the code that we use to send webhooks when events occur on that platform.
  
  
• We've improved the performance of petition details page for admins.
  
  
• We've changed the way that cookie banner consent works. The cookie that we store indicating consent is now stored for a longer time period. We've also begun the work of deferring the use of analytics tools until users have accepted the use of cookies. This is already working for Segment users, and we plan to support other third-party analytics tools soon. 
  
  
• While searching for a member by email address, we now do a better job of filtering out stray spaces.
  
  
• We've updated the way we track whether a user has been added to a partner's mailing list. Previously we set join_group to true or false depending on the user's opt-in status. We've made the column more intuitively named by renaming it to join_partnership.
  
  
• We've improved the formatting of pre-formatted text in certain emails. 
  
  
• We’ve made significant changes in the way we handle email bounces throughout the platform. Previously, when an email bounced, was invalid or was marked as spam we silently blocked future delivery to that email address internally. 
  
  We've now extended that behavior to make email bounces visible and propagate them to our customers as unsubscribes. With this change, we're now unsubscribing members who (1) have entered an email address that we can not deliver to permanently (2) have affirmatively marked messages as spam (3) are malformed in some way. 
  
  We've also added a 'source' field to unsubscribes. This reflects the mechanism through which an unsubscribe has been created. It can either be web, api, bounce, admin, spam, or invalid. These source codes are available through our webhooks and bulk data APIs and can be used to determine whether or not these unsubscribes should be recorded in your other systems. For CRMs like ActionKit if you have configured Unsubscribe sync these new unsubscribe events should continue to flow to your CRM. Unfortunately we're not aware of a CRM that allows us to send raw email bounce email information, which is why we are sending unsubscribe events in this case. 
  
  Unsubscribe Sources:
  api: unsubscribe created through our REST API.
  admin: a platform admin user manually unsubscribed this member.
  web: a member unsubscribed themselves via the web.
  bounce: the email bounced back to us as permanently undeliverable.
  spam: the member marked an email as spam in their email client.
  invalid: this email address is malformed or invalid in some way that prevents us from even attempting to send. 
  
  This is not a functional change to our toolset: we've never continued to send email to these email addresses in these cases, but it is a change in visibility to customers when email delivery is being blocked. Since many members take their first action with ControlShift we are often the first system to realize that an email address may be undeliverable. By exposing these events in our API in addition to processing them internally, we hope customers can improve their deliverability by never attempting to send email to invalid addresses we've detected. 
  
  Coming very soon will be a web dashboard where your team can more easily monitor bounces and overall platform deliverability. Previously this capability was only available to our largest customers with direct access to our ESP. 
  
  We're also planning to make setting up Email Deliverability authentication via SPF/DKIM mandatory for all of our customers in order to continue to send mail through the platform. You can get a head start on this on a self service basis via Settings > Deliverability in your platform settings. You'll soon see a warning prompting you to complete this step when you sign in as an administrator. In the meantime, setting up Email Deliverability authentication will be a prerequisite for our deliverability monitoring features. 

Petitions

Updates / Bug Fixes

• We've re-added the place name autocomplete to the new decision maker in an effort form. It was temporarily removed in favor of a different location search component, but the autocomplete is back. 
  
  
• We fixed an issue where for organizations using email confirmation (also known as double opt in). A user who followed a malformed confirmation link could in some circumstances have the comment they left on a petition associated with the incorrect user. We completed an audit of the email confirmation code and the misattributed comments were the only impact of this bug.

Events

Updates / Bug Fixes

• We've released a new feature that allows organizations to change the default event creation form to prioritize virtual events instead of in-person events (Meaning that users will see the time zone dropdown when creating a new event instead of seeing the location search.) To enable that change, go to Settings > Options > Events > Virtual events by default. †
  
  
• We're now including attendee limits in the event moderation modal. This will allow organizations who are moderating in-person events to set limits on the number of attendees during moderation. Once the attendee limit is reached, new users will be added to the wait list. †
  
  
• For events whose host information has been overridden, we were still using the host account's first name in the sign off of the thank you for RSVPing emails. (The overridden name was being used as the 'from name' for the email). We're now using the overridden name in the thank you email's sign off as well. 
  
  
• We've updated the way we pull external events into the platform to make this process faster and improve performance platform-wide. 
  
  
• We've updated the new event form to more consistently display form fields in a consistent size.
  
  
• We've invested in improved tooling to speed up our deployment process in order to get new features to you even faster. 

Groups

Updates / Bug Fixes

• We're now allowing admins to move events into local groups. Admins can go to the event's admin page > Associations section to add an event to the group. These events will be shown on the group page and attendees will be asked to join the local group. †

Nothing new in VisitThem.

† This feature required new text strings. If you're using the platform in a language other than English, you may need to provide updated translations.