Skip to main content

Data Residency & Tenant Isolation

This document explains where the information you enter into Boxcurve Unity is stored, the circumstances in which information leaves your Microsoft 365 tenant, and how your data is kept isolated from other organisations. It is written for security, data-protection, procurement and IT-administration reviewers assessing Boxcurve Unity for deployment in their own Microsoft 365 tenant.

The document follows the evidence in the application itself: every statement about what Boxcurve Unity does, and, importantly, what it does not do, is drawn from the application's own connections and automated processes. Where the platform (rather than the application) determines a behaviour, that is labelled and you are directed to Microsoft's own documentation rather than given a second-hand explanation.

Note, shared-responsibility model

Three parties shape data residency and isolation for Boxcurve Unity: the Microsoft Power Platform, which hosts the application and stores its data in your tenant; Boxcurve, which supplies the application and operates a single licensing endpoint; and you, the customer, who control your tenant configuration and any integrations you choose to connect. This document separates the three throughout.

1. Where your data resides​

Boxcurve Unity is a Power Platform application backed by a Microsoft Dataverse database, together with a set of automated processes (cloud flows). It runs entirely inside your own Microsoft 365 tenant and your own Power Platform environment.

The business information you enter into Boxcurve Unity is stored in your tenant's Dataverse database. There is no separate, Boxcurve-hosted application database. Boxcurve does not operate a copy of your projects, stakeholders, tasks, role assignments or any other working data on your behalf.

Because Dataverse storage location and data residency are platform behaviours determined by Microsoft and your tenant's configuration, not by Boxcurve Unity, refer to Microsoft's own documentation for the authoritative position on Dataverse data location, geography and residency:

Note

Boxcurve Unity inherits the data-residency posture of the Dataverse environment you install it into. If you require data to remain in a specific Microsoft geography, that is governed by how your Power Platform environment is provisioned, which is under your control.

2. What information the application stores​

All of the following is stored in your tenant's Dataverse database and is owned and controlled by you. Described in business terms, Boxcurve Unity holds:

  • Projects and their operational and master structure, including project names and numbers.
  • Stakeholders and stakeholder mappings, the people and groups associated with a project.
  • Tasks and task lists, including descriptions, categories, services, frequency, completion status and assignments.
  • Accountability assignments, who is Responsible, Accountable, Consulted or Informed (and the related assignment letters) for each task.
  • Role and access assignments within the application, linking users to projects and to their in-application roles.
  • User settings, including each user's locally held licence-power value.
  • In-application notifications received from the licensing endpoint (see Section 4).
  • Error logs recording the application module, error code and message, environment name, and the email address of the user whose action encountered the error, for diagnostic purposes.

Boxcurve Unity contains no custom code, there are no plug-ins, no custom components and no embedded scripts. There is therefore no application-supplied mechanism that could copy or transmit this data outside the channels described in this document.

For a fuller breakdown of stored fields and their handling, see the Data Held & Handling document.

3. Connections the application uses​

Boxcurve Unity reaches other services in two distinct ways, and a reviewer should treat them separately:

  1. Connectors, the named Microsoft connectors the application is built on. These are the services the application is wired to use.
  2. Direct calls made inside automated processes, outbound web requests issued from within the application's cloud flows. These do not appear in the connector list and must be inspected inside the processes themselves; they are enumerated in Section 4.

3.1 Connectors​

The application uses the following connectors, all of which are Microsoft connectors operating within the Microsoft service boundary:

  • Microsoft Dataverse, the application's own database in your tenant.
  • Office 365 Outlook, sending mail (for example, task-assignment notifications).
  • Office 365 Groups, group membership and ownership operations.
  • Office 365 Users, looking up user details within your directory.
  • OneDrive for Business, exporting data (for example, CSV exports) to a user's OneDrive.
  • Planner, creating and synchronising tasks in Microsoft Planner.
  • Microsoft Teams, Teams-related operations.
  • Azure DevOps, creating work items on an Azure DevOps board you configure.

In addition, the application relies on standard Power Platform internal connectors used to manage and run its own flows and apps. These are platform plumbing, not data destinations.

Each of the connectors above connects to a Microsoft service. Whether information reaches a given service depends on whether you and your users use the corresponding feature (for example, no Planner data is exchanged unless you use the Planner synchronisation). How each connector authenticates and behaves is governed by Microsoft Power Platform and your tenant's configuration; see the Integrations & Connections document for the operational detail.

3.2 No non-Microsoft connectors​

Aside from the direct in-process calls enumerated in Section 4, the application's connectors are all Microsoft connectors. There is no connector to a non-Microsoft data store, analytics service, advertising service or third-party platform. This is the evidence underpinning the residency position: the absence of external connectors is verifiable in the application's own connection list, not merely asserted.

4. Where information can leave the tenant​

This section is deliberately precise. Rather than claim that "no data ever leaves your tenant", it names every channel through which information can leave, what each one sends, and who controls it.

There are two categories: customer-configured integrations (you choose whether to connect them, and you point them) and the built-in licensing check (supplied by Boxcurve).

4.1 Customer-configured external integrations​

Two automated processes make outbound calls to non-Microsoft services. Both require you to supply the credentials and parameters, so both are under your control, they do nothing unless you configure and trigger them.

monday.com task import. When a user imports tasks from a monday.com board, the application calls the monday.com API using a monday.com API key and board identifier that the user supplies at the time. Task data (such as task names) is retrieved from monday.com into your tenant. Because the API key is provided by the user, this integration is entirely customer-controlled; if you never provide a monday.com key, no call to monday.com is made.

Task-pack content retrieval. When loading shareable task lists, the application retrieves task-pack content from Boxcurve's task pack repository, using an access token. This is a read operation that brings reference content into your tenant; the business data you enter is not sent out as part of it.

Caution, customer responsibility for external integrations

The monday.com integration sends a credential you supply to a non-Microsoft service and is governed by that service's own terms and data handling, not by Boxcurve. If your data-governance policy restricts connections to external services, control these integrations through your tenant's data loss prevention (DLP) policies. DLP configuration is a Power Platform administrator function; see https://learn.microsoft.com/power-platform/admin/wp-data-loss-prevention.

The Azure DevOps connector (Section 3.1) likewise connects to a service you point to. Azure DevOps is a Microsoft service, but the specific Azure DevOps organisation it writes to is one you configure; information sent there is governed by your Azure DevOps tenancy.

4.2 The built-in licensing check (Boxcurve-operated)​

Boxcurve Unity performs a licensing and plan check against a single Boxcurve-operated endpoint hosted on Azure API Management. This is the only channel through which Boxcurve itself receives any information, and it is the only outbound call the application makes that is not initiated by a customer-configured integration.

What it transmits. When the licensing check runs, the application sends to the Boxcurve endpoint:

  • your tenant identifier (the Microsoft tenant ID, supplied automatically by the platform);
  • your environment identifier (the Power Platform environment ID, supplied automatically);
  • a product key identifying the Boxcurve Unity offering;
  • a last-notification marker, the highest identifier of notifications already received, so the endpoint can return only newer notifications; and
  • an assigned-licence summary, a count, grouped by plan, of distinct stakeholder maps. This is an aggregate usage figure for licence reconciliation; it does not include stakeholder names, task content or other business data.

The endpoint returns the current plan and subscription status, version information (used to show an "update available" message), and any new notifications, which are stored as in-application notifications in your Dataverse.

Note, this is the full extent of what Boxcurve receives

The licensing payload above is the only information Boxcurve receives from the application. Boxcurve Unity contains no analytics, no usage tracking, no cookies and no telemetry beyond this check, consistent with the application containing no custom code. Your business data (projects, stakeholders, tasks, accountability assignments) is not part of the licensing payload and is not sent to Boxcurve.

Behaviour when the endpoint is unreachable (fail-open). This is a common reviewer question, so it is stated explicitly. The licensing check is not a gate on application access:

  • User access and navigation into the application are determined before the licensing check runs, based on whether the user is recognised as a stakeholder in your tenant. A failed or unreachable licensing endpoint does not sign the user out or block them from the application.
  • If the licensing call fails or times out, no plan data is returned; the application's licence collection is simply empty for that session, the derived licence-power value falls back to its default, and the "update available" message logic falls back to default version values. The failure is recorded in the application's error log.

In other words, the application fails open with respect to access, an outage of the Boxcurve licensing endpoint degrades licence-dependent indicators but does not lock users out of their own data in their own tenant.

4.3 Summary of outbound channels​

ChannelDestinationDirectionControlled byCarries business data outside tenant?
Licensing checkBoxcurve endpoint (Azure API Management)OutboundBoxcurve (built in)No, only tenant and environment IDs, product key, notification marker, aggregate licence counts
monday.com importmonday.com (non-Microsoft)Inbound to tenantYou (credentials you supply)No, retrieves task data into your tenant
Task-pack retrievalBoxcurve's task pack repositoryInbound to tenantYou (token) and Boxcurve contentNo, retrieves reference content into your tenant
Azure DevOpsAzure DevOps organisation you configureOutboundYou (your DevOps tenancy)Yes, task and work-item data you choose to send
Office 365 / Planner / Teams / OneDrive / OutlookMicrosoft services in your tenantWithin Microsoft boundaryYou (feature use)Within your Microsoft 365 boundary

5. Tenant isolation​

Boxcurve Unity stores its data in your tenant's Dataverse and relies on the Power Platform's own tenant-isolation guarantees. Isolation between your organisation's data and any other organisation is a platform behaviour provided by Microsoft Dataverse and Microsoft Entra ID, not something the application implements.

Within your tenant, access to records is further constrained by the application's own security roles and by Dataverse security (business units, security roles and row ownership). How users are authenticated and authorised into the application is covered in the Identity & Access Control document.

For the platform-level guarantees that one tenant's data is isolated from another's, refer to Microsoft:

6. Encryption at rest and in transit​

Encryption of Boxcurve Unity's data, both at rest in Dataverse and in transit between the application, the flows and the Microsoft services it uses, is provided by the Microsoft Power Platform, not by the application. Boxcurve Unity does not implement its own cryptography and does not store data outside the platform-provided, encrypted stores.

For the authoritative, current detail on how Microsoft encrypts Dataverse data at rest and in transit, refer to Microsoft:

The outbound calls described in Section 4 are made over HTTPS. The internal handling of those requests by Power Automate and the receiving Microsoft services is a platform behaviour; see the Microsoft references above.

7. Summary for reviewers​

  • Boxcurve Unity runs in your Microsoft 365 tenant and stores its data in your Dataverse. There is no Boxcurve-hosted copy of your business data.
  • The application contains no custom code, so there is no application-supplied mechanism to exfiltrate data outside the channels documented here.
  • All of the application's connectors are Microsoft connectors. There is no connector to a non-Microsoft data store.
  • The only information Boxcurve receives is the licensing-check payload: tenant ID, environment ID, product key, a notification marker and an aggregate licence count. No business data, analytics or tracking is sent to Boxcurve.
  • The licensing check fails open with respect to access, an outage does not lock users out.
  • Information can reach non-Microsoft services only through integrations you configure (monday.com import; task-pack retrieval) and through the Azure DevOps organisation you point to. Govern these through your tenant's DLP policies.
  • Tenant isolation and encryption are platform guarantees provided by Microsoft; see the Microsoft Learn and Service Trust Portal references above.