Architecture and Security in Salesforce

Overview

DayBack is a Canvas App in Salesforce, meaning its application code is hosted on DayBack's servers at dayback.com rather than within your Salesforce pages. This allows for frequent updates without the need for customers to install new packages. When bug fixes and new features are pushed to the server, customers benefit from them immediately.

Because of this setup, some application settings are also stored on DayBack's servers. This document outlines the division of labor between DayBack and Salesforce, detailing which information is stored where.

Details

Security review

DayBack has successfully passed the rigorous security review required for all AppExchange apps. For Canvas Apps, this review includes testing DayBack's servers, conducting penetration tests, checking for injection vulnerabilities, and examining all traffic between dayback.com and Salesforce.

Where is my event data stored?

Throughout the remainder of this document, the term "event" refers to any Salesforce record displayed on the DayBack calendar, such as an appointment. This could include records from the native Event object in Salesforce, a Task, a Campaign, or any custom object you have chosen to show on the calendar.

• No Event Storage: Events are stored only in Salesforce and do not pass through DayBack's servers when displayed on the calendar.
• In-Page Data Query: DayBack uses the REST API via the Canvas SDK to query Salesforce, and this is done entirely within your Salesforce pages.
• No Shadow Tables: DayBack does not maintain an event database or shadow tables on its servers.

Does DayBack respect our profiles and role hierarchy?

Yes. The REST API runs under the authentication of the logged-in user, utilizing the Signed Request authentication flow provided by the Canvas SDK. Therefore, a DayBack user has no more and no less access to their Salesforce data than they do on other Salesforce pages.

What is stored on DayBack's servers?

DayBack records your calendar settings on its own servers. This includes all the information in the "admin" side of DayBack:

• Calendar Sources: Information on the calendar sources you use, as shown above
• Admin Settings & Defaults: Settings from the "Admin Settings & Defaults" section of the DayBack admin screen, such as default view, time increments, start time, etc.
• Status and Resource Names: Names of your statuses, resources, resource folder names, and status colors. For resources, only the name is stored, not the resource's ID (even if the resource represents a Salesforce record).
• Custom Actions: If you've created custom actions to customize DayBack, the code for those actions is stored on DayBack's servers.
• User Information: DayBack records the email address of each Salesforce user authorized to use DayBack and who actually uses the app. This includes emails of users designated as DayBack admins. Only the identifying information about the user is stored—their org ID, email address, and Salesforce record ID. No passwords or other sensitive user identification details are kept. Note that the email address stored is not the Salesforce user's username/account name. Here is an example of the actual data recorded for the users of DayBacks test drive org in Salesforce:

{
  "group" : {
    "id" : "sf-org-00D36000000ojIYEAY17381-23517tk"
  },
  "members" : {
    "1459229742595-1900723854" : {
      "account" : "[email protected]",
      "admin" : true,
      "id" : "1459229742595-1900723854",
      "userID" : "sf-005360000015SOJAA221107-29573tk"
    },
    "1459305409187-0976614575" : {
      "account" : "[email protected]",
      "admin" : false,
      "id" : "1459305409187-0976614575",
      "userID" : "sf-005360000015SOUAA2-1931-93222tk"
    },
    "1468520557325-2375843162" : {
      "account" : "[email protected]",
      "admin" : false,
      "id" : "1468520557325-2375843162",
      "userID" : "sf-005360000015SQZAA261098-2231tk"
    }
  },

Here's a diagram of how data moves between Salesforce, the user's browser, and DayBack's servers:

This data is backed up daily and retained for 30 days.

What about sharing?

The sharing feature in DayBack is specifically designed to publish calendar data to people outside your Salesforce org. You can turn this capability off or restrict it to certain users. Event data can only leave Salesforce when you manually create a public bookmark. For details on how this works and what data is actually published, see sharing.

Sharing is similar to exporting your event data. A share recipient has no access to your Salesforce org. Bookmarks "shared" with "just me" or "my group" do not leave Salesforce; only public bookmarks allow data to be accessed outside of Salesforce.

Infrastructure

Where are DayBack's servers?

DayBack's storage is hosted on a Firebase Cloud Firestore server in the United States. You can learn more about Firebase locations here. During DayBack's security review with Salesforce, the team thoroughly inspected all traffic between DayBack and the server to ensure it was secure, using WSS (secured web sockets).

Our application itself is hosted on Digital Ocean's servers, using region based load balancing. The servers are located in San Francisco US, London England, and Sydney Australia. Users will connect to the server located closest to their location, or based on server availability.

Encryption

Data is encrypted at rest and in transit.

Data at Rest:

• Data is encrypted with server-side encryption.
• Firebase manages cryptographic keys using the same robust key management systems that Google uses for its own encrypted data, including strict key access controls and auditing.
• Each Firestore object's data and metadata are encrypted under the 256-bit Advanced Encryption Standard.
• Encryption keys are themselves encrypted with a regularly rotated set of master keys.

Data in Transit:

• We use Transport Layer Security (TLS) for data in transit.

Datacenter certifications

Firebase Cloud Firestore:

• Successfully completed ISO 27001, ISO 27017, and ISO 27018 evaluations.
• Also compliant with SOC 1, SOC 2, and SOC 3. More details can be found here.

DigitalOcean:

• Certified in the international standard ISO/IEC 27001:2013. More details can be found here.