Calendar 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.

Visitors booking an appointment on your site get the same experience: seeing appointment slots fade from view as other customers book them.

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.)

Reacting to Event Streams

If you'd like to program a response to receiving a stream update, DayBack includes a new app action trigger that will fire when an update is received: "On Event Stream Update."

(If you haven't worked with app actions before, you can learn more about them here.)

Here is a simple example that will show a message to let a user know something they are looking at has been changed or added. Users will see something like "<event title> was modified" or "... was deleted."

// Show Toast on Stream Update

// Purpose: Shows a message to let a user know something in view has been changed, added, or delted.
// Action Type: On Event Stream Update
// Prevent Default Action: No

// More info on custom App Actions here:
// https://docs.dayback.com/article/140-custom-app-actions

notifyEventEdit();
async function notifyEventEdit() {
  const operation = params.data.streamData.operation;
  const methods = params.data.methods;
  const outOfRange = params.data.outOfRange;
  if (outOfRange) {
    return
  }
  if (operation === 'edit' || operation === 'create') {
    const event = await methods.getEvent();
	if (!event) {
    	return;
  	}
	dbk.showMessage(`"${event.title}" was ${operation === 'create' ? 'created' : 'modified'}`, null, null, 'notify');
  }
  else if (operation === 'delete') {
  	const event = methods.getDisplayEvent();
    if (!event) {
      return;
    }
    dbk.showMessage(`"${event.title}" was deleted and removed from your current view`, null, null, 'notify');
  }
} 

Note that the "ourOfRange" attribute tells us if the streamed event is available in the current date range/calendar. You can go further, using the "isShown" attribute to know if the event is literally visible, vs being on another resource page or filtered out of view with resource or status filters.

There is also a "deferred" attribute available to the action: that will be true if the update has been received but not yet acted upon because another action is blocking DayBack from reacting. For example, a modal popover might be open.

And here is a little CSS to make the toast blue to distinguish it from the "Undo" and "Error" messages you might otherwise see at the bottom of the screen.

.message-notify .message-content {
	background-color: rgba(51,122,183,0.75);
}

You can set "Prevent Default Action" to "Yes" if you'd like to stop DayBack from drawing streamed events, or use "  " inside a branch of your action to only draw in some cases: like only for events of a specific status (note that you will have to retrieve the event to have access to its status—only a few things are sent with the stream broadcast. The event ID and Calendar are sent, but the status is not. See "Privacy and Security in the Event Stream" below for exactly what is sent.

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.