Introduction

This article describes the data flow in NITRO Apps and the related security aspects. Different scenarios are considered and described in terms of data storage, access and flow. Please contact Crow Canyon support if you need any additional information for any particular App or scenario.

Client Side Apps

Most of the NITRO Apps are implemented entirely in JavaScript, e.g. NITRO Forms, Reports, Power Portal etc. In this case data doesn’t flow outside of SharePoint and there are no additional security considerations except for what are there for standard SharePoint functionality. Please note following points:

1. NITRO App code runs in the browser entirely. There is no component that is running outside of the browser or outside of user machine
2. Crow Canyon services running in Azure are not involved except for the license check. Script code calls the Crow Canyon licensing service that is running in Microsoft Azure to check if license is valid. For this it passes the Site URL and App Name and gets back the license status value (Trial including date/Expired/Product etc.). No user information or site data is passed as part of this check
3. NITRO App code uses standard SharePoint JavaScript API (JSOM) to read the data stored in SharePoint lists wherever required for the App functionality
4. NITRO App code doesn’t collect any statistics, site data or user information and doesn’t pass it to any outside server
5. Code runs in the context of user who is logged in to the SharePoint site and the data user can access is limited by the permissions he has via the SharePoint permissions

Crow Canyon Workflow Manager and Approval Workflow

There are two types of Workflows from the data security perspective. We will use the abbreviation WF to refer to the Crow Canyon Workflow Application that is running in Microsoft Azure.

Event Based Workflows

These workflows are triggered on specific events in SharePoint like when a SharePoint list item is created or modified. Many business processes are configured to run on these events and data security is explained for this by taking a sample scenario:

Scenario: Send a mail to user when an existing Ticket is assigned to them

Workflow Configuration: On Tickets list, create a workflow on item updated event. If ‘Assigned Staff’ user field value has changed and there is a valid user specified, then send a mail with predefined format and Ticket details to the user specified in the ‘Assigned Staff’ column in the Ticket item. Please note that this Workflow configuration doesn’t have any data related to actual Tickets or the users, it is just based on the List name, event, column names and mail format with placeholders for Ticket columns etc.

Data Storage: Tickets item data is there in SharePoint just like any other list data and is accessible to users via login to SharePoint. Workflow configuration details are stored in Crow Canyon Azure Database as Xml/JSON and is not encrypted

Data Flow – Versioning is enabled on List:

1. Manager user who is logged into SharePoint edits a Ticket and specifies the name of the staff user who should be working on the Ticket. After entering the required data in Ticket edit form, manager clicks Save button
2. Workflow web application (WF app) running in Azure receives an event with details of list and item that is being updated
3. Since versioning is enabled on list, SharePoint will maintain the item column values in previous version of the item (before change). There is no need to store item data to Crow Canyon Azure database
4. Ticket Save operation completes and Ticket item is modified and has the new user in ‘Assigned Staff’ column
5. WF app receives an event with details of list and item that is updated
6. WF app reads the Tickets item data again using same process and keeps it in memory (not stored in any persistent medium). Same is done for the previous version of the item data
7. Item is updated at this point so this is the Ticket data after the Manager user has modified it (after change)
8. As per the workflow configuration, WF app verifies if ‘Assigned Staff’ value has changed and there is a valid user value in it. This is done by comparing the two sets of data that the WF App has for the Ticket. ‘Before change’ data that is read from previous version of item, and ‘after change’ data from latest version. Both of these are in memory and not stored anywhere
9. If ‘Assigned Staff’ value has changed then prepare the email content by replacing Ticket column values in the mail format that is stored as part of workflow configuration
10. Connect to Microsoft Exchange server specified in WF settings for the current site and send the mail
11. In memory data is discarded automatically by the Microsoft ASP.Net framework

Data Flow – Versioning is not enabled on List:

1. Manager user who is logged into SharePoint edits a Ticket and specifies the name of the staff user who should be working on the Ticket. After entering the required data in Ticket edit form, manager clicks Save button
2. Workflow web application (WF app) running in Azure receives an event with details of list and item that is being updated
3. WF app reads the Tickets item data from SharePoint using REST API and stores it in the Azure SQL Db after encrypting it using AES. This connection from Azure servers to SharePoint servers is over HTTPS using standard SharePoint API and is entirely within the Microsoft domain. Crow Canyon does not have any third-party servers taking part in this process and doesn’t access this data in any way
4. Note that this data is stored in database only if Workflow or the Mail Template configuration has reference to item data before its modification. Otherwise, no data is stored in the database during this event
5. Item is not yet saved so this is the Ticket data before the Manager user has modified it (before change)
6. Ticket Save operation completes and Ticket item is modified and has the new user in ‘Assigned Staff’ column
7. WF app receives an event with details of list and item that is updated
8. WF app reads the Tickets item data again using same process and keeps it in memory (not stored in any persistent medium)
9. Item is updated at this point so this is the Ticket data after the Manager user has modified it (after change)
10. As per the workflow configuration, WF app verifies if ‘Assigned Staff’ value has changed and there is a valid user value in it. This is done by comparing the two sets of data that the WF App has for the Ticket. ‘Before change’ data is read from SQL and is decrypted, ‘after change’ data is available in memory directly
11. If ‘Assigned Staff’ value has changed then prepare the email content by replacing Ticket column values in the mail format that is stored as part of workflow configuration
12. Connect to Microsoft Exchange server specified in WF settings for the current site and send the mail
13. Delete the ‘before change’ data stored in SQL Db
14. In memory data is discarded automatically by the Microsoft ASP.Net framework

Timer/Scheduled Workflows

These workflows are triggered based on the data time values in the SharePoint list items. Many business processes are configured to execute specific actions before or after the date value and data security is explained for this by taking a sample scenario:

Scenario: Send a mail to assigned staff of the open Ticket one day after the due date

Workflow Configuration: On Tickets list, create a workflow based on the ‘Due Date’ column. Workflow is to be triggered one day after the date value specified in the ‘Due Date’ column. If Ticket is still open then send a mail with predefined format and Ticket details to the user specified in the ‘Assigned Staff’ column in the Ticket item. Please note that this Workflow configuration doesn’t have any data related to actual Tickets or the users, it is just based on the List name, column names, time difference and mail format with placeholders for Ticket columns etc.

Data Storage: Tickets item data is there in SharePoint just like any other list data and is accessible to users via login to SharePoint. Workflow configuration details are stored in Crow Canyon Azure Database as Xml/JSON and is not encrypted

Data Flow:

1. Workflow service application (WF service) running in Azure servers runs every 30 minutes to process timer based workflows
2. WF service reads the Workflow configuration from Azure SQL Db. Based on the date column and time difference it will fetch the matching Ticket items from SharePoint
3. WF service reads the matching Tickets data from SharePoint using REST API and keeps it in memory. This connection from Azure servers to SharePoint servers is over HTTPS using standard SharePoint API and is entirely within the Microsoft domain. Crow Canyon or any other third party do not have any servers outside of Microsoft network taking part in this process and don’t access this data in any way. Also, this data is not stored in any persistent medium
4. As per the workflow configuration, WF service verifies if Ticket is still open by checking the value of ‘Status’ column
5. If Ticket is open then prepare the email content by replacing Ticket column values in the mail format that is stored as part of workflow configuration
6. Connect to Microsoft Exchange server specified in WF settings for the current site and send the mail
7. Repeat the above steps for all matching Ticket items
8. In memory Tickets data is discarded automatically by the Microsoft .Net framework

Crow Canyon Email Sync

This App monitors new mails coming to a mailbox and creates those mails in a SharePoint list. While configuring the App user specifies the mailbox details including the user name and password to read the emails. Password is stored in Azure SQL Db after encrypting it using AES algorithm. Configuration also includes the SharePoint site and list details where emails have to be created.

Date Flow:

1. Email Sync application (ES service) running in Azure servers runs every few minutes to check for new mails in configured mailboxes
2. ES service reads the configuration from Azure SQL Db. Based on the mailboxes specified, it will connect to the Microsoft Exchange using the Exchange Web Services API
3. ES service reads the new emails one by one keeps the data in memory. This connection from Azure servers to Microsoft Exchange servers is over HTTPS using standard API and is entirely within the Microsoft domain (if using O365 mail accounts, otherwise it connects to customer’s/hosted Exchange server). Crow Canyon or any other third party do not have any servers outside of Microsoft network taking part in this process and don’t access this data in any way. Also, this data is not stored in any persistent medium
4. As per the email sync filter configuration, ES service verifies if email is to be created in SharePoint
5. Connect to SharePoint site as per settings and create a new list item with details of email and add attachments. This connection from Azure servers to SharePoint servers is over HTTPS using standard SharePoint API and is entirely within the Microsoft domain. Crow Canyon or any other third party do not have any servers outside of Microsoft network taking part in this process and don’t access this data in any way. Also, this data is not stored in any persistent medium
6. Repeat the above steps for all new emails that have come since last sync
7. In memory email data is discarded automatically by the Microsoft .Net framework

For more information on the design principle of framework app, please refer this Microsoft article.