How Xoralia accesses your information

How Xoralia accesses your information

Xoralia uses a Microsoft verified Entra ID Enterprise Application to communicate with your Microsoft 365 tenant. Our Enterprise Application uses a mix of delegated and application permissions, which we describe below.

During installation, you will be presented with a permission request like below. This details each of the permissions that Xoralia requires to carry out it’s operations. These permissions are not individually configurable and are required to be accepted by a Microsoft 365 Global Administrator (or Entra Administrator) for Xoralia to work correctly.

Delegated permissions are a type of permission that requires a signed in user to be accessing the application and the operation will be performed on behalf of that user. For example, a delegated operation might be to view a list of files from a SharePoint site – Xoralia will perform this as a delegated query and will query that information as the logged in user, meaning it will only display information to the user that they have access to from that SharePoint site.

Application permissions are a type of permission that does not require a signed in user and will allow the Xoralia application to perform operational and service level tasks without user interaction. An example of this is a library synchronisation that Xoralia performs every 10 minutes to check for updates in SharePoint document libraries.

Xoralia requests the following Microsoft Graph permissions:

    • Send a teamwork activity as the user

        • Type: delegated

        • Reason: Used by our Microsoft Teams app to send notifications to users

    • Sign in and read user profile

        • Type: delegated

        • Reason: Allows the user to sign in to Xoralia and access information within Xoralia

    • Have full control of all site collections

        • Type: delegated

        • Reason: Allows Xoralia administrators to associate libraries to Xoralia to which they have access. Also allows users to read documents within Xoralia to which they have access.

    • Send a teamwork activity to any user

        • Type: application

        • Reason: Used by our Microsoft Teams app to send notifications to users

    • Read all users’ full profiles

        • Type: application

        • Reason: Xoralia allows document owners to target documents to users. This permission allows Xoralia to view users inside of your Microsoft 365 tenant to know which users are to be targeted.

    • Send mail as any user

        • Type: application

        • Reason: As a Xoralia adminstrator, you can set which email address should send notifications (such as must read and expiry notifications). This permission allows Xoralia to do that.

    • Read all groups

        • Type: application

        • Reason: Xoralia allows document owners to target documents to groups. This permission allows Xoralia to view groups inside of your Microsoft 365 tenant to know which users are to be targeted.

    • Read all group memberships

        • Type: application

        • Reason: Xoralia allows document owners to target documents to groups. This permission allows Xoralia to view groups inside of your Microsoft 365 tenant to know which users are to be targeted.

    • Create, edit, and delete items and lists in all site collections

        • Type: application

        • Reason: Xoralia can create libraries and add meta data columns to associated libraries when an Xoralia administrator triggers that action. This permission allows that control – Xoralia will only ever create libraries when a Xoralia administrator requests so and will never use this permission for any other action. This permission is also used by the Xoralia sync process to update library and document information.

    • Read installed Teams apps for all users

        • Type: application

        • Reason: Allows Xoralia to find the Teams app inside of your tenant to send targeted notifications to users (such as Must Read notifications)

You can limit who can access Xoralia by going to Enterprise Applications within Microsoft Entra ID and opening the Xoralia Policy Management app. Once you have this open, select properties and enable the ‘Assignment required?’ option. Save this property and open the ‘Users and Groups’. With this setting enabled, only users and groups listed here will be able to access Xoralia. Add your users and groups here using the ‘Add user/group’ option.

Invite Guest User to Active Directory

Adding external users as a guest

These instructions guide you through the process of inviting external guests to your Azure Active Directory. By following these steps, you can seamlessly add collaborators who aren't part of your organization, making collaboration in the Azure environment a breeze.

Invite Guest User to Active Directory

1. Login to Azure Portal via

2. Expand the left menu by clicking the top left button.

3. Click “Microsoft Entra ID”.

4. Click “Users”.

5. Click “+ New user” -> “Invite external user”.

6. Type in the email address of the external guest to be invited in the “Email” textbox. Fill in “Display name” of the external guest.

7. Fill in information under “Properties” tab.

8. Add AD groups which this guest user should be in.

9. Click “Review + invite”.

10. Verify the information is correct and then click “Invite”.

Download user guide: Adding external users as a guest

Caching and performance

Caching and performance

Xoralia has been built to be efficient and under most circumstances will load libraries and reports fast. It has been tested in scenarios with libraries containing over a thousand documents.

In order to achieve fast speeds and performance at all times we have had to put in place some caching functions. This is because querying SharePoint at page load time can be slow, especially with large libraries containing many documents. Whilst standard users are not likely to be affected by this, document owners might notice irregularities caused by caching.

It’s useful to know how caching works so that you do not get any unexpected results when using Xoralia: the system queries SharePoint document libraries at 10 minute intervals and caches the results. When a user loads a library Xoralia is returning the contents of the cache. This means the list of documents is at most 10 minutes old. Any documents uploaded into a document library within this 10 minute window might not show up until the cache is refreshed by the system. Document owners who upload a document into SharePoint and then want to start working on them immediately in Xoralia should wait up to 10 minutes before the documents will appear and actions such as assigning documents can be carried out.

Please note, caching does not affect ‘Documents I must read’. This list is always up to date and loads instantly.

Download user guide: Caching and performance

Application security, load testing and threat protection

Application security, load testing and threat protection


This article will cover all application security, data encryption and threat protection elements of Xoralia. Any further information required can be requested from [email protected].

Application Security

The Xoralia application infrastructure has been built with security at the forefront. All Azure services that are utilised are protected by both Azure Application Gateway Web Application Firewalls and Azure Virtual Networks. This ensures that only valid, secure traffic is passed on to Xoralia web apps and APIs.

Within the application itself, we have utilised the following technologies / techniques:

  • Azure SQL Auditing
  • Microsoft Defender for Cloud
  • Azure Transparent Data Encryption
  • Azure Key Vault

All staff working across the Xoralia platform are running Windows 10 or later compliant devices and using company-managed antivirus, malware and firewall systems. Content Formula staff are background checked prior to joining the team.

Data encrypted at rest and in transit

All data stored on Xoralia servers is encrypted at rest using Azure Transparent Data Encryption. All data in transit is sent over HTTPS connections only. HTTPS is enforced on all web apps and APIs.

Under load testing and scalability

Xoralia has been tested under high loads (>5000 active users) and has passed all tests as expected.

The Xoralia application architecture allows us to proactively monitor and instantaneously scale the application on demand should it be needed. In the event of high load on 1 service, the application monitoring will automatically scale that service until normal operations are realised.

Backup, retention and location of Xoralia data

Backup, retention and location of Xoralia data


In this article, we will describe how Xoralia handles backups, what data is backed up and retained on Xoralia systems and where that data is stored. Any further information required can be requested from [email protected].

What data is stored on Xoralia

Xoralia uses the following information:

  • Active Directory usernames (UPN)
  • Active Directory first and last names of users
  • Active Directory group names (of groups that are used in Xoralia only)
  • Document filenames and IDs
  • Document meta data that has been set inside of Xoralia (tags, review dates, assignments)
  • SharePoint site names, URLs and IDs
  • SharePoint document library names, URLs and IDs
  • Document reporting information (who has read, who has been assigned, when a document was read, which version was read)
  • System auditing information (system logins, who assigned a document, who updated metadata)

At no point does Xoralia consume or store the contents of any documents stored on SharePoint or any other platform. Xoralia only stores the names of people who are assigned documents or those who have some sort of privileged access such as document owners, Xoralia admins etc.

Back up policies

Xoralia backs up all data listed above every 24 hours in differential backups with point in time backups occurring every 7 days. All backups are stored for 7 days. Recovery of information usually takes less than 3 hours if required. Xoralia does not copy or back up your actual documents at any point since these are stored in your SharePoint instance. If any recovery needs to be made within SharePoint, Microsoft’s standard SharePoint back up policy backs up data every 12 hours and typical recovery times are less than 12 hours. If in doubt please check with Microsoft.

Retention of data

Once a customer has ended their association with Xoralia, all data relating to that installation will be removed from Xoralia systems within 90 days.

Location of data

During installation of Xoralia, you can choose which location your data will be stored in at rest. Currently Xoralia supports two Azure regions: UK South and Central US. Customers can select their favoured data residency location during installation.

How to configure SharePoint permissions with Xoralia

How to configure SharePoint permissions with Xoralia


When associating a SharePoint library with Xoralia, Xoralia will respect any permissions that have been set in SharePoint: if a user does not have access to a document, Xoralia will never show that document to the user. Similarly, if you would like to make a document assignment to a user in Xoralia, they must already have access to the SharePoint site before they will be able to view the document. Be sure to check out our article about the Xoralia permissions model in conjunction with this article.

Which SharePoint permissions are required?

For a user to be able to see a document in Xoralia, they must have at least Read access to the SharePoint document library.

Assigning permissions is quite straightforward in SharePoint, however they can get more complex the more rules that you enforce across your different libraries. SharePoint typically works on an inheritance model – if you have access to the top level site, you have access to everything therein. However, you can break this inheritance for certain libraries or files. We would normally recommend that you do not break inheritance and that you apply permissions at a site level as management of this can become somewhat cumbersome, although we do recognise that on occasion you may want to break this inheritance and give one library different permissions to another – Xoralia will respect any individual permissions you set up like this.

To assign permissions to an entire SharePoint site, simply navigate to the site homepage, click the SharePoint cog in the top right corner and then click on Site Permissions. Then clicking on Advanced Site Permissions will display a page that will typically show 3 groups (more may appear here depending upon the changes you’ve already made to site permissions previously): Owners, Members and Visitors

Visitors: anyone you would like to be able to consume your documents in Xoralia should be a Visitor – Visitors have Read access over your SharePoint site and therefore your SharePoint document libraries associated with Xoralia.

Members: usually people who have edit permissions across your site and libraries – anyone you add here will be able to add, edit and delete documents from your SharePoint site and libraries. Anyone in this group will have Read permission as well.

Owners: the users listed here have all of the permissions above but can also manage permissions and perform more site-wide operations. Should be limited to very few users typically.

To add a user, simply click the group you wish to add a user (or Active Directory group) to, and select New. Type your user(s) name in the box that pops up and choose under Show Options if you wish to notify them that you have granted permission. Once you have added the user here, within a few minutes they will have access to your Xoralia libraries that have been associated with this site.

How can I manage multiple users with SharePoint permissions?

SharePoint permissions supports Microsoft Groups and Active Directory security groups by default. We’d recommend that you create groups when assigning permissions in SharePoint. These groups can also be used when making assignments to documents in Xoralia.

The Xoralia permissions model

The Xoralia permissions model

In order to carry out certain tasks in Xoralia a user needs to have the correct permissions. Some of these permissions are set inside Xoralia and others are set inside SharePoint. Please refer to our article ‘How to configure SharePoint permissions with Xoralia‘.

The Xoralia permissions model:

Roles and permissions

Office 365 tenant admin

Where is the permission set?

Required to carry out the one-time installation of Xoralia inside your Office 365 tenant. Office 365 tenant admin centre

Xoralia admin

Associates Xoralia with relevant document libraries inside SharePoint Xoralia admin panel
Manages various Xoralia settings such as branding Xoralia admin panel
Grants reporting-only access (see ‘Reporting’ below) Xoralia admin panel

Document library owner

Has full access to all documents inside a library (see ‘Document owner’ below) SharePoint permissions

Document owner

Has access to edit documents inside a library SharePoint permissions
Has ability to set document expiry dates Document owner column in the document library
Has ability to assign documents as mandatory reads Document owner column in the document library
Has ability to add other document owners Document owner column in the document library
Has access to reporting access Document owner column in the document library


Required to access reporting only for a specified document library Xoralia admin panel

Document reader

Can read a document SharePoint permissions
Can attest a mandatory document has been read When doc owner assigns a document as mandatory read

Download user guide: The Xoralia permissions model

PHP Code Snippets Powered By :

We use cookies to give you the best experience on our site. By continuing to use our website, you are agreeing to our use of cookies. To find more about the cookies, please see our Cookie notice

You can also read about our Privacy policy

Contact Support

If you have a question about Xoralia software, please fill out the form below and a member of our support team will be in contact with you shortly.