Event Streaming

Introduction

The event stream brings edits from other users into everyone's calendar in real time.

If someone else adds, edits, or deletes an event on a day visible in your calendar, you'll see that event appear, move, or disappear automatically (without you having to take any action). This prevents users from overwriting each other's work. It also makes sure that no other user silently takes an appointment slot out from under you while you're contemplating a booking.

Event Streaming is Ideal for these Use Cases

• Creative Teams: Anywhere multiple users have access to edit the same event.
• Call Centers: Ensure that the open slots you see aren't being grabbed by other users.
• Online Booking: Customers can see available slots disappear from the calendar in real time as they get booked by other customers or by your call center.
• Field Service: Same-day appointment changes get pushed to your users without them having to refresh the calendar.

Enabling Event Streaming in Your DayBack

Streaming is off by default. You can turn it on in the Misc section of admin setting. (Event Streaming requires DayBack's Plus plan, which you already have if you're using Salesforce.)

Limitations

Notifications in the event stream are broadcast from changes made in DayBack's interface. This includes having DayBack use your own card windows in FileMaker.

But changes made outside of DayBack, in Salesforce modals or other Salesforce pages will not trigger a streaming notification by default. You'll want to use a webhook to ping DayBack's Streaming Service if you'd like those edits broadcast. Please get in touch and our team can help set that up for you.

Privacy & Security in the Event Stream

None of your event details pass through DayBack's servers as part of streaming. When a user creates, edits, or deletes an event, DayBack sends a few details about that change to our servers. We don't receive any PHI or PII and don't see any of the text from your event. Here is what DayBack receives and broadcasts to all connected users in your same DayBack group:

• Event ID: the primary key of the event in your data source
• Calendar ID: DayBack's internal UUID for your calendar
• Calendar Type: DayBack's internal UUID for your calendar source (Salesforce, Google, etc)
• Original Event Start and End Timestamps: when this event took place before editing
• New Event Start and End Timestamps: when this event takes place now
• Operation: Is this a creation, edit, or deletion
• Unscheduled State: Boolean: Did this edit affect the event's unschedule state
• User ID: DayBack's internal UUID for the user making the change
• Presence ID: DayBack's internal UUID for the session in which the change was made
• DayBack Group ID: DayBack's internal UUID for the group the event-modifying user belongs to

Here is a screenshot of what this actually looks like on our server (these records are destroyed after 72 hours):

For more details on how your event data stays in your data sources without passing through DayBack's servers, see our Architecture and Security briefs for Salesforce, FileMaker, Google, or MS365.