Boxcurve Unity: Capabilities & Data Access

This document describes what people can do in Boxcurve Unity, what business information each capability reads or updates, and which roles may use it. It is written for the security, compliance and IT-administration teams of an organisation running Boxcurve Unity in its own Microsoft 365 tenant.

Boxcurve Unity maps operational processes and accountability across your projects and operations. Its core capability is the Accountability Map: a grid that records who is responsible for each item of work. The application supports your chosen responsibility format: RACI, RASCI, RATSI, DACI, DCI or MOCHA.

Boxcurve Unity is a Power Platform application backed by Microsoft Dataverse, supported by a set of automated cloud flows. It contains no custom code, and it provides no artificial-intelligence capability that users operate (see A note on artificial intelligence). All business information it works with is held in your own Dataverse environment, inside your Microsoft 365 tenant (see Where the information lives).

How access is determined

Before any business data is shown, Boxcurve Unity establishes who the signed-in user is and what they are allowed to do. Two checks govern access:

1. Sign-in and identity. The user signs in with their organisational (Microsoft Entra ID) account. Authentication is handled entirely by Microsoft, Boxcurve Unity does not maintain its own credentials. For how sign-in itself works, see Microsoft's documentation: https://learn.microsoft.com/entra/identity/.

2. Membership of the stakeholder list. Boxcurve Unity keeps a list of the people who participate in the application (its stakeholder records). A user who is not on that list, or who lacks permission to read it, is shown an access-denied screen and cannot reach any project data. The first-time setup screens are reachable only by a user holding the environment's System Administrator security role; everyone else is directed to an access-denied screen until setup is complete and they have been added.

Application roles

Within the application, what a user can see and do is governed by five roles. A user's role is derived from their membership of the Microsoft 365 groups that Boxcurve Unity associates with the relevant project. The roles are:

Role	Intended for
Administrator	Application administrators who configure and operate Boxcurve Unity.
Operations Manager	Operations managers overseeing projects and assignments.
Project Manager	Managers responsible for an individual project.
Team Manager	Managers responsible for a team within a project.
User	Team members who view and work their own assigned tasks.

In the application these roles carry a "RACI" prefix, for example the Administrator role appears as RACI Administrator and the user role as RACI User.

Role assignment is operated by your administrators through the application's settings, which add or remove users from the corresponding Microsoft 365 groups and Dataverse security roles. The mapping of capability to role is summarised in Capabilities by role. The role model is described in full in the Identity & Access Control document.

What users can do

The capabilities below are grouped by area as a user encounters them in the application.

Working with the accountability map

The central capability is the Accountability Map, a grid of tasks against the people or roles responsible for them, scoped to a single project. The map records responsibility in your chosen format, such as RACI, RASCI, RATSI, DACI, DCI or MOCHA. From the map a user can:

• browse the tasks for the currently selected project, grouped by category and service;
• search and filter tasks, for example by department, by task type, by tag, by responsibility assignment, or to show only tasks changed since the user last signed in;
• open an individual task to view or edit it (see Editing a task);
• assign responsibility for a task to a person or role.

The map reads task information, the assignment records that link tasks to people or roles, the project's stakeholder records, and the project's departments.

Selecting an accountability model

In Boxcurve Unity the accountability format is chosen per project: each project, and the Accountability Map it carries, has its own format, set when the project is configured. Different projects in the same environment can therefore use different formats.

Boxcurve Unity supports six formats:

Format	Role letters
RACI	R Responsible · A Accountable · C Consulted · I Informed
RASCI	R Responsible · A Accountable · S Supportive · C Consulted · I Informed
RATSI	R Responsible · A Authority · T Task · S Support · I Informed
DACI	D Driver · A Approver · C Contributors · I Informed
DCI	D Decision Maker · C Consulted · I Informed
MOCHA	M Manager · O Owner · C Consultant · H Helper · A Approver

The format selected for a project determines which role letters are available on that project's Accountability Map and how each letter is labelled. Each model is described in full in Appendix: Accountability models in Boxcurve Unity.

Editing a task

Opening a task lets an authorised user view and maintain its details. A task carries business information including its name and description, its category, service and subcategory, its frequency and priority, risk indicators, compliance references, documentation and reference links, tags, free-text notes, its lifecycle phase and status, and scheduling details such as a start date and the days of the week on which it recurs.

On a task, users can also:

• Add comments. A comment captures the message text together with the name, e-mail and identity of the person who wrote it at the time, providing a per-task discussion and record.
• Mark tasks complete and close tasks. Whether a given user may close a task is governed by a configurable, role-based setting that your administrators control (Manage who can close tasks by role).

Assigning responsibility

Users with the appropriate role can assign a task's responsibility to a specific person, working from the project's stakeholder records. This updates the assignment records that connect tasks to people within the accountability map.

Viewing your own tasks

Each user has a personalised view of the tasks assigned to them, and of the tasks belonging to their department, drawn from the accountability map for the projects they participate in. This is how the application scopes day-to-day work to the individual, see How visibility is scoped.

Comparing projects

Boxcurve Unity lets users compare the accountability maps of different projects side by side, so that tasks and assignments can be reviewed across projects.

Reporting

A reporting area presents information drawn from the accountability map and task data for the selected project.

Reviewing task changes

A task change log lets users review the history of changes to tasks and assignments. Each entry records the area affected, the event, the field that changed, its old and new values, who made the change, and when. This change history is generated automatically as records are modified.

Settings and administration

Managers and administrators have an administration dashboard and a settings area from which they operate the application. Capabilities available here include:

• managing users and their roles (adding or removing users, assigning and removing application roles);
• creating new projects, and the supporting groups and teams for a project;
• project lifecycle operations such as copying, backing up, restoring, resetting and deleting a project, and promoting a development copy of a project;
• importing and exporting task and stakeholder data (see Integrations);
• configuring automated task synchronisation and scheduling, including how many days in advance recurring tasks are created and the daily time at which that runs.

Within this area, individual operations are themselves restricted by role: the most sensitive operations, such as project deletion, user and role management, and data import and export, are reserved for the Administrator.

How visibility is scoped

Boxcurve Unity scopes what each user sees in two reinforcing ways:

• By participation. A user must be present in the stakeholder list to access any project data. The personalised "my tasks" and "my department's tasks" views return only the tasks associated with that user (and their department) for the projects in which they participate.
• By role and Dataverse security. Each application role corresponds to a Dataverse security role that defines the permitted operations on the underlying records. Record ownership and business-unit boundaries (per project) constrain which records a user can read or change. Dataverse enforces these permissions on the server; the application's screens reflect them.

The mechanics of Dataverse security roles and record-level security are a Power Platform topic. See Microsoft's documentation: https://learn.microsoft.com/power-platform/admin/security-roles-privileges.

Capabilities by role

The table below summarises which roles may use each capability. Everyday capabilities, viewing the accountability map, working your own and your department's tasks, commenting, and reviewing the change log, are available to all roles. The administration dashboard is open to the four management roles (Administrator, Operations Manager, Project Manager and Team Manager); within it, the most sensitive operations are reserved for the Administrator.

Capability	Available to
View the accountability map and tasks	All roles
View own and department tasks	All roles
Add comments to tasks	All roles
Review the task change log	All roles
Compare projects	All roles
Edit and assign tasks	Users holding the appropriate role for the task's project
Close and complete tasks	Governed by the configurable "who can close tasks by role" setting
Reach the administration dashboard	Administrator, Operations Manager, Project Manager, Team Manager
Manage users and role assignments	Administrator
Import and export task and stakeholder data	Administrator
Project lifecycle operations (create, copy, backup, restore, reset, delete, promote)	Reserved for the Administrator, with selected operations also open to other management roles
First-time setup	A user holding the environment's System Administrator security role

The authoritative permission for every capability is enforced by each role's Dataverse security configuration. Administrators can confirm the exact privileges on each role in the Power Platform admin experience, and the full role model is described in the Identity & Access Control document.

Information held and handled, in business terms

All of the following resides in your Dataverse environment. The application does not hold business data anywhere else. The data categories below are described in full in the Data Held & Handling document.

Information area	What it covers
Tasks	The work items in the accountability map: name, description, category/service/subcategory, frequency, priority, risk indicators, compliance references, documentation and reference links, tags, notes, lifecycle phase, status, and scheduling details.
Assignments	The records linking tasks to the people or roles responsible (the accountability-map entries).
Stakeholders and people	The participants in the application: name, e-mail, organisation, position, department, jurisdiction, and stakeholder attributes (type, role description, impact, influence, risk tolerance).
Projects	The projects (and their supporting business units, teams and groups) that scope the accountability maps.
Departments, categories and jurisdictions	Reference data used to organise tasks and people.
Comments	Per-task discussion entries, with the commenter's name, e-mail and identity captured at the time.
Notifications	In-application notifications: title, message, type, timestamp, and read/critical status.
Change log	The automatically generated history of changes to tasks and assignments (field, old value, new value, who, when).
Task packs	Reusable sets of pre-defined tasks.
User settings	Per-user preferences and state (for example, when the user last signed in).
Error log	Diagnostic records the application writes when it encounters an error, including the screen, error message and the signed-in user's e-mail.
AI-governance reference attributes	The stakeholder records include a set of optional governance attributes for recording details of an AI agent (for example model and provider identification, intended use and limitations, audit ownership and dates, logging configuration and retention, and high-risk indicators). These are reference fields that an administrator may complete; Boxcurve Unity does not itself invoke any AI service against them (see A note on artificial intelligence).

This document describes these areas in business terms only; it does not reproduce the underlying table or field names.

A note on artificial intelligence

Boxcurve Unity provides no artificial-intelligence capability that users operate: there is no feature in the application that generates, summarises, classifies or otherwise processes your data with an AI model, and the application makes no call to any AI service.

The stakeholder records do include a set of optional governance reference attributes for documenting an AI agent, for example a model name and provider, its intended use and limitations, audit ownership, logging and retention settings, and high-risk indicators. These are descriptive fields only: they let an administrator record governance information about an AI agent that exists elsewhere. Completing them does not cause Boxcurve Unity to run any AI process. The provider options offered for one of these fields are a fixed list of provider names used as labels for recording metadata, not an integration with those providers.

Where the information lives

All business information described above is stored in your organisation's own Microsoft Dataverse environment, within your Microsoft 365 tenant. Boxcurve Unity reads from and writes to that Dataverse; it does not maintain a separate, vendor-hosted copy of your data.

How Dataverse stores and secures data, and where your environment is geographically located, are Power Platform topics. See Microsoft's documentation: https://learn.microsoft.com/power-platform/admin/capacity-storage and https://learn.microsoft.com/power-platform/admin/regions-overview.

Answering accountability questions through Microsoft 365 Copilot

Because Boxcurve Unity holds your accountability information as structured data in Dataverse, that information can become an authoritative source for natural-language questions asked through Microsoft 365 Copilot, once your organisation chooses to enable it.

By default, Microsoft 365 Copilot grounds its answers on content in the Microsoft Graph, such as mail, documents, chats and meetings. That content has no definitive record of who is accountable for what; Copilot can only loosely infer accountability from unstructured material, which is unreliable. Boxcurve Unity fills that gap. Its Accountability Map records, in a structured form, who is responsible for each item of work, in your chosen format such as RACI, RASCI, RATSI, DACI, DCI or MOCHA, together with the supporting stakeholder records, departments and roles, across your Project and Operational contexts. When Dataverse data is made available to Microsoft 365 Copilot in your tenant, Copilot can answer questions grounded on this authoritative Unity data rather than inferring from documents.

In practice, a team member, for example a new joiner, could ask Microsoft 365 Copilot in plain language:

• "What is my accountability in this team?"
• "Who is accountable for X?"
• "Who does what on this team or project?"
• "Where do I find X in my organisation, and who owns it?"

This is an emergent platform capability, not a Boxcurve Unity feature

It is important to be precise about responsibility here. Boxcurve Unity does not include, build or require any Copilot integration or connector, and there is nothing for Boxcurve to configure in Unity to make this work. Unity's role is simply that it structures your accountability data in Dataverse. The natural-language answers are produced by your own Microsoft 365 Copilot, using Microsoft's built-in ability to ground Copilot on Dataverse data. This capability is therefore enabled and operated entirely within your Microsoft 365 environment.

:::info Customer-enabled, with conditions This capability is off until your administrator turns it on, and it depends on your Microsoft 365 environment, not on Boxcurve Unity. Before relying on it, note the following:

• You enable it. Dataverse data must be made available to Microsoft 365 Copilot in your tenant by your administrator. There is nothing for Boxcurve to configure in Unity.
• Licensing applies. It requires Microsoft 365 Copilot licensing. Surfacing answers inside the application additionally requires the relevant Power Apps premium licensing.
• It is read-only. Copilot answers and summarises; it cannot create, change or delete any Unity data. Taking action on Unity data from a natural-language request would require a separate custom agent, which is out of scope for Boxcurve Unity.
• It respects your existing permissions. Copilot returns only the Unity data a user is already authorised to see; it inherits Unity's access model. A new joiner sees only what their role permits (see How visibility is scoped).
• Answer quality depends on your data. The usefulness of any answer depends on how completely and accurately your Accountability Maps and stakeholder records have been populated and modelled.
• Some surfaces are still in preview. Core support for Dataverse data in Microsoft 365 Copilot reached general availability on 29 May 2026; some related surfaces remain in Microsoft public preview. Confirm the current state of each surface against Microsoft's documentation before depending on it. :::

Enabling and configuring this capability is performed in your Microsoft 365 environment, not in Boxcurve Unity. For the prerequisites and the administrator toggles involved, see Microsoft's official documentation:

• Dataverse data in Microsoft 365 Copilot: https://learn.microsoft.com/en-us/power-apps/maker/data-platform/data-platform-data-copilot
• Enable Microsoft 365 Copilot (admin prerequisites and toggles): https://learn.microsoft.com/en-us/power-apps/maker/model-driven-apps/add-microsoft-365-copilot

The connection context for surfacing Unity data to other Microsoft 365 services is described further in the Integrations & Connections document.

Integrations: where information leaves or enters the application

Several capabilities exchange information with other services. In each case the connection is made from within your tenant, using connections your administrators configure, and is subject to your tenant's data-loss-prevention and connector governance. Boxcurve Unity uses these services; it does not change how the services themselves work.

Capability	Service	Direction	What is exchanged
Create tasks in a plan; sync task status; pull tasks	Microsoft Planner	Both ways	Task details and status are created in, and read back from, Planner.
Create a work item from a task	Azure DevOps Boards	Outbound	A task is created as a work item on a DevOps board.
Export tasks	OneDrive for Business	Outbound	Tasks are written to a CSV file in OneDrive for Business.
Add high-level roles as group owners	Microsoft 365 Groups	Outbound	Designated users are added as owners of a Microsoft 365 group.
Import tasks from monday.com	monday.com	Inbound	Boards and tasks are read from monday.com (a non-Microsoft service) over its API.
Import task lists	Boxcurve's task pack repository	Inbound	Pre-defined task lists are imported from Boxcurve's task pack repository.

The application also connects to Microsoft Teams and to Office 365 (Outlook, Users and Groups) to support the capabilities above, for example resolving user profiles, sending notifications and working with the Microsoft 365 groups that back each project. monday.com is the only third-party (non-Microsoft) service; it, and the import of pre-defined task lists from Boxcurve's task pack repository, are optional: they are used only where your administrators choose to configure the corresponding import and supply its connection and credentials. The integration boundary and connection setup are described in full in the Integrations & Connections document.

For the Microsoft services above (Planner, Azure DevOps, OneDrive, Microsoft 365 Groups, Teams and Office 365), how each service itself works is out of scope here; see Microsoft's documentation at https://learn.microsoft.com/.

What Boxcurve Unity provides versus what you operate

• Boxcurve Unity provides the application, its capabilities, its roles, the cloud flows that drive automation and integrations, and the Dataverse data model that holds your information.
• Your organisation operates the Microsoft 365 tenant and Dataverse environment in which it runs, the user accounts and group memberships that determine roles, the connections used by the integrations, and your own data-loss-prevention and security policies.

Appendix: Accountability models in Boxcurve Unity

Boxcurve Unity records responsibility on each Accountability Map using one of six accountability models. The model is chosen per project (see Selecting an accountability model), and it determines the role letters available on that project's map and how each letter is labelled.

The role labels below are exactly how Boxcurve Unity labels each letter. The "when it suits" notes are general project- and operations-management guidance to help you choose a model; they describe the models in the abstract and do not imply any model-specific behaviour, automation or limit within Boxcurve Unity itself, which treats all six models the same way.

Comparison at a glance

Model	Role letters (as labelled in Unity)	Emphasis and when it suits
RACI	R Responsible · A Accountable · C Consulted · I Informed	The common general-purpose baseline. Distinguishes who does the work from who is ultimately answerable, and who is consulted or merely kept informed. Suits most projects and routine operational processes.
RASCI	R Responsible · A Accountable · S Supportive · C Consulted · I Informed	RACI with an explicit Supportive role added, for people who actively help carry out the work without owning it. Suits work where supporting contributors are significant and should be named separately.
RATSI	R Responsible · A Authority · T Task · S Support · I Informed	Emphasises the split between Authority (who can decide or approve) and the Task itself, alongside the people responsible, supporting and informed. Suits situations where decision authority and task ownership need to be kept distinct.
DACI	D Driver · A Approver · C Contributors · I Informed	A decision-oriented model. A single Driver moves the work forward, an Approver signs off, Contributors provide input and others are Informed. Suits decision-making and initiatives that need clear ownership of the decision and its approval.
DCI	D Decision Maker · C Consulted · I Informed	A lean, decision-focused model with only three roles: who decides, who is consulted, who is informed. Suits lightweight processes where a fuller model would add unnecessary overhead.
MOCHA	M Manager · O Owner · C Consultant · H Helper · A Approver	An ownership- and management-oriented model that names a single Owner accountable end to end, with a Manager, Consultant, Helper and Approver around them. Common in operations and recurring work where clear ownership matters.

RACI

• R — Responsible
• A — Accountable
• C — Consulted
• I — Informed

RACI is the most widely used general-purpose model. It separates the person who performs the work (Responsible) from the single person ultimately answerable for it (Accountable), while recording who should be Consulted and who is simply kept Informed. It is a sound default for most projects and for routine operational processes.

RASCI

• R — Responsible
• A — Accountable
• S — Supportive
• C — Consulted
• I — Informed

RASCI extends RACI with an explicit Supportive role for people who actively help carry out the work without owning it. It suits work where supporting contributors are significant enough to be named in their own right rather than folded into "Responsible" or "Consulted".

RATSI

• R — Responsible
• A — Authority
• T — Task
• S — Support
• I — Informed

RATSI emphasises the distinction between Authority (who can decide or approve) and the Task itself, alongside who is Responsible, who provides Support, and who is Informed. It suits situations where decision authority and task ownership need to be held visibly apart.

DACI

• D — Driver
• A — Approver
• C — Contributors
• I — Informed

DACI is a decision-oriented model. A single Driver keeps the work moving, an Approver provides sign-off, Contributors supply input, and others are Informed. It suits decisions and initiatives that need an unambiguous owner of both the work and its approval.

DCI

• D — Decision Maker
• C — Consulted
• I — Informed

DCI is a lean decision model with only three roles: who makes the decision, who is consulted, and who is informed. It suits lightweight processes where a fuller model would add more structure than the work requires.

MOCHA

• M — Manager
• O — Owner
• C — Consultant
• H — Helper
• A — Approver

MOCHA is an ownership- and management-oriented model that names a single Owner accountable from end to end, supported by a Manager, Consultant, Helper and Approver. It is common in operations and recurring work, where clear, individual ownership is the priority.