Boxcurve Unity: Data Held & Handling

This document describes the information that the Boxcurve Unity application holds inside your Microsoft 365 tenant, where personal data is involved, how access to that information is controlled, the handling behaviour the application provides, and where information can leave your tenant through optional integrations. It also sets out the responsibilities that remain with you as the customer, in particular, defining your own classification scheme, retention periods and disposal rules.

This document is written for your data protection officers and IT-governance teams.

Privacy at a glance

Boxcurve Unity is a Power Platform application that runs entirely inside your own Microsoft 365 tenant. Your projects, tasks, stakeholders, comments and accountability-map data are held in your own Microsoft Dataverse and never leave your tenant, except through the optional integrations that you choose to configure (see Section 4).

Boxcurve receives no business or personal data. The single, named exception to "nothing leaves the tenant" is the application's periodic licensing check, which sends Boxcurve a minimal licensing payload only: your tenant identifier, your environment identifier, a fixed product-key value, a last-notification marker, and an aggregate licence summary (a count of distinct accountability maps per plan). It contains no business content and no personal data.

Beyond this licensing payload, Boxcurve collects no other data at all, no usage analytics, no cookies and no tracking. The application contains no custom Boxcurve code; it is built entirely from standard Power Platform components.

Where Boxcurve Unity stores data

All of Boxcurve Unity's application data is held in Microsoft Dataverse within the Power Platform environment you provision in your own Microsoft 365 tenant. Boxcurve Unity does not operate a separate, vendor-hosted data store. Storage, encryption-at-rest and tenant isolation are provided by the Power Platform; Boxcurve Unity relies on those platform behaviours rather than implementing its own. For how Dataverse handles storage, encryption and tenant boundaries, see Microsoft's documentation: https://learn.microsoft.com/power-platform/admin/ and the Microsoft Service Trust Portal: https://servicetrust.microsoft.com/

1. What information the application holds

Boxcurve Unity is an accountability-mapping and task-management application. It maps responsibility for work across your projects and operations using whichever responsibility format your organisation works in, for example RACI (Responsible, Accountable, Consulted, Informed), RASCI, RATSI, DACI, DCI or MOCHA. Projects are organised as either Project or Operational in nature. The information the application holds falls into the following business categories.

Projects and project configuration

Each project record holds descriptive and operational information about a project, including the project name, number, description, project type, project owner, a project logo, and the accountability-map format the project uses (for example RACI, RASCI, RATSI, DACI, DCI or MOCHA). Project records also hold configuration values that point the application at the external locations you choose to connect it to (for example, identifiers for an associated Microsoft 365 group, a Teams team and channel, a Planner plan, and an Azure DevOps organisation and project name). These configuration values are operational settings rather than business content.

Tasks and the Accountability Map

The application holds a library of tasks and the Accountability Map that assigns responsibility for those tasks. Task records hold information such as the task name, description, category, type, frequency, priority, risk score, jurisdiction, notes, tags, documentation links, and a free-text classification value (see "A note on the task classification field" below). The Accountability Map records link tasks to departments and record the assigned responsibility (for example the RACI letter), the task status, and approval and escalation details, including who approved an entry and when, and the equivalent details for removal requests.

Departments, categories, task packs and jurisdictions

The application holds reference data used to organise tasks: departments, task categories, jurisdictions, and "task packs" (predefined sets of tasks, which may carry a vendor, platform, service and a source link from which they were sourced).

Stakeholders

The application holds a stakeholder register. Stakeholder records contain personal and organisational information about individuals associated with a project (see "Where personal data is held" below).

Comments

Users can record comments against tasks. Each comment holds the comment text together with information identifying the person who made it at the time it was made.

Notifications

The application holds in-app notification records, including a title, message, type, date and time, and flags indicating whether a notification is active, critical, or has been read in the app. Some of these notification records originate from Boxcurve as part of the licensing check (for example product or version notices) and are written into your Dataverse; they carry no business or personal data.

User settings and application settings

The application holds per-user preference records (for example, a user's email, pinned projects, a flag controlling whether a tutorial message is shown, and a last-login value) and tenant-wide application settings (name/value configuration entries used to control application behaviour).

Change history

For certain records, tasks, the Accountability Map, and the stakeholder-to-map assignments, the application keeps change-history records that capture a copy of the changed information along with who made the change. See the Activity Logging & Audit Evidence document for how this change history is used as audit evidence and for the depth of platform auditing.

Error log

The application records technical error events to support troubleshooting. An error record may include an error code, message, context, the application module and component involved, the environment, and the email address of the user who encountered the error.

AI agent governance information

Stakeholder records can additionally hold a set of AI-agent governance attributes, for example a model name, version, provider, intended use, limitations, a model-card link, audit ownership and criticality, audit dates, and a log-retention value expressed in days. These are descriptive governance fields that record information about an AI model or agent; they are entered and maintained by your administrators. The application itself performs no AI processing, these fields are a register your administrators keep, not an AI capability of the product. The log-retention value here is a value your administrators record against an agent for their own governance purposes; it is not a retention rule that the application enforces against the data it stores.

Where personal data is held

The following information held by the application may constitute personal data and should be treated accordingly under your data protection obligations:

• Stakeholder register, stakeholder first name, last name, full name, title, position, email address, organisation, role description, comments, and assessment values such as impact, influence and risk tolerance. This is the primary location of personal data about people who are not necessarily users of the application.
• Comments, the name, first name, last name and email of the person recorded against a comment at the time it was made, alongside the comment text.
• Change history, the display name, email and identity reference of the person who made a recorded change.
• User settings, a user's email address and last-login time.
• Error log, the email address of the user who encountered a recorded error.
• Approval and escalation details on Accountability Map records, the identity of approvers and the related dates.
• Project owner and similar ownership/assignment fields that reference individuals.

In addition, Dataverse automatically records, on most records, the user who created and last modified the record, and when. This is standard Power Platform behaviour rather than a Boxcurve Unity feature.

All of this personal data sits in your Dataverse, under you as data controller. Boxcurve, as processor, holds only the minimal licensing payload described in the Privacy at a glance callout, which contains no personal data.

A note on the task classification field

Task records include a free-text classification field. This field describes the task (it is part of the task's descriptive content) and is not a governed data-sensitivity or information-classification scheme. Boxcurve Unity does not apply Microsoft sensitivity labels and does not implement an information-classification scheme of its own. Classification of the information held in the application is Customer-defined (not provided by the application).

2. How access to that information is controlled

Access to the information above is controlled by the application's security roles, which your administrators assign to users. The application defines five roles, identified here by function. (In the application these roles are currently labelled with a "RACI" prefix, for example the Administrator role appears as RACI Administrator.)

• Administrator
• Operations Manager
• Project Manager
• Team Manager
• User

These roles grant progressively broader access, with the Administrator role the broadest and the User role the most limited. Roles determine which records a user can read, create, update, delete and export, and at what scope. Detailed role behaviour, including the per-record-type privileges of each role and how data export is gated, is covered in the Identity & Access Control document. For how identity and sign-in are handled, the application relies on Microsoft Entra ID; see Microsoft's documentation: https://learn.microsoft.com/entra/

Because all application data is held in Dataverse, the underlying record-level and field-level security model is provided by the Power Platform. Boxcurve Unity uses that model through the roles listed above. For how the Power Platform security model works, see Microsoft's documentation: https://learn.microsoft.com/power-platform/admin/

3. Handling and restriction behaviour the application provides

The handling behaviour that Boxcurve Unity itself provides over the information it holds is:

• Role-based access, as described in Section 2, restricting who can view, change and export information.
• Change history captured for tasks, the Accountability Map and stakeholder-to-map assignments, recording what changed and who changed it.
• Approval and escalation tracking on Accountability Map entries, recording approvals, removals and escalations together with the responsible person and dates.
• Soft state on records, records carry a status that allows them to be deactivated rather than only deleted (standard Dataverse record-state behaviour that the application uses).

The application does not provide its own data-classification or sensitivity-labelling scheme, application-enforced retention, expiry, archival or automated disposal of stored data, or application-level field masking or redaction of the personal data it holds. Where such controls are required, they are the customer's responsibility (see Section 5) and are implemented through the Power Platform and Microsoft Purview rather than within Boxcurve Unity.

4. Where information can leave your tenant

The single Boxcurve-bound flow of information is the licensing check described in the Privacy at a glance callout, which sends only the minimal licensing payload (tenant identifier, environment identifier, product-key value, last-notification marker and an aggregate licence summary) to Boxcurve's licensing service. No business or personal data is included in that exchange.

Beyond the licensing check, Boxcurve Unity offers optional integrations. When you enable and configure an integration, some of the information the application holds can be sent to the connected destination. The destinations are:

Integration	What can leave the application	Destination
Microsoft Planner	Task information, to create and synchronise tasks in a Planner plan	Microsoft Planner (within your Microsoft 365 / Microsoft cloud)
Microsoft Teams and email notifications	Notification content sent to assigned individuals	Microsoft Teams and Microsoft 365 email (within your Microsoft cloud)
Azure DevOps	Task information, to create work items on a DevOps board	Azure DevOps
CSV export to OneDrive	Exported task/Accountability-Map information written as a CSV file	OneDrive for Business (within your Microsoft 365)
monday.com	Task/board information exchanged with a monday.com board	monday.com (a non-Microsoft, external service)
Boxcurve task packs	Retrieval of predefined task-pack lists	Boxcurve's task pack repository

Important points for your assessment:

• The Microsoft Planner, Teams/email, Azure DevOps and OneDrive integrations send information to Microsoft services. Whether those services are inside your tenant boundary depends on your own Microsoft 365 and Azure configuration. See the Data Residency & Tenant Isolation and Integrations & Connections documents.
• The monday.com integration communicates with a non-Microsoft external service over the internet, calling monday.com's API directly. The task-pack import retrieves predefined task-pack lists from Boxcurve's task pack repository; this is a read-only retrieval of reference content. Both reach a location outside your Microsoft 365 tenant. You should review them against your data protection and third-party-sharing obligations before enabling them.
• Each integration runs only when you have configured and enabled it. The connections that integrations use, and who owns them, are covered in the Integrations & Connections document.

The specific data fields included in each outbound transfer beyond the categories above are not exhaustively enumerated here; where an exhaustive field list is required for a data protection assessment, it should be confirmed for the specific integration you intend to enable.

5. Shared responsibility and customer responsibilities

Responsibility for the information in Boxcurve Unity sits across three layers:

• Microsoft operates the underlying Power Platform and Microsoft 365 services, including Dataverse storage, encryption-at-rest and tenant isolation.
• Boxcurve provides the Boxcurve Unity application and processes only the minimal licensing payload described above; it holds no business or personal data.
• You, the customer, are the data controller for all business and personal data the application holds in your Dataverse, and you operate the governance controls below.

The following are your responsibilities as the customer operating Boxcurve Unity in your tenant. The application does not provide them and you must define and operate them under your own policies:

• Data classification scheme, defining how the information held in the application is classified for sensitivity and handling. Customer-defined (not provided by the application).
• Retention periods, defining how long each category of information (including stakeholder personal data, comments, change history and the error log) is kept. Customer-defined (not provided by the application).
• Disposal rules, defining how and when information is deleted or anonymised at the end of its retention period. Customer-defined (not provided by the application).
• Lawful basis and data-subject rights, establishing the lawful basis for holding stakeholder and user personal data, and operating data-subject access, correction and erasure requests against the records described in Section 1. Because this personal data resides in your Dataverse under you as controller, you operate these requests through the Power Platform and Microsoft Purview; Boxcurve holds only the licensing payload, which contains no personal data. Any specific lawful-basis statement is a business/legal input for your organisation to determine, it is not provided by the application.
• Decisions on outbound integrations, deciding whether to enable each integration in Section 4, particularly the monday.com integration and the Boxcurve task-pack import, and assessing the resulting data flows.

Retention, disposal, classification labelling and data-loss-prevention controls over the underlying data are implemented through the Power Platform and Microsoft Purview. For how to configure these platform capabilities, see Microsoft's documentation: https://learn.microsoft.com/power-platform/admin/ and https://learn.microsoft.com/purview/

Related documents

• Identity & Access Control, detailed role privileges and how export is controlled.
• Data Residency & Tenant Isolation, where data is stored and processed.
• Activity Logging & Audit Evidence, how change history is used as audit evidence and the depth of auditing.
• Integrations & Connections, the connectors each integration uses and how they are set up.