How access works

A role decides what a person can open and do. A report share supplies access to a particular published report and sets limits on its records and columns. A Brightspace launch can add a course boundary. Check all three before relying on a sharing setting.

Roles and report shares

Each person has one Rowseta role, which is a set of permissions. A share does not add permissions to that role. For example, opening a shared report still needs Open shared reports and Access Analytics, and a share never opens someone else’s draft. See Roles and permissions for the default grants and fixed rules.

See all report data opens published reports with all records, columns and names, regardless of their shares. Other people’s drafts still need See other people’s drafts. Write SQL also overrides share limits on rows, columns and personal column masking in reports the person can already open, in an app session without the launch course cap. It does not open additional reports. A signed launch course boundary still applies; See all report data does not remove that course boundary either. See All rows in reports.

Without those overrides, Rowseta checks a person share first, then matching group shares, then role sharing. Where matching shares are combined, their settings are combined rather than applied as separate filters. Automatic child expansion is not applied to a combination. Older shares with a Brightspace base role can inherit row, enrollment and child settings. This is why one card’s settings may not describe a person’s final access. Check Report sharing and Test as.

Records and columns

Org unit scope chooses which parts of the Organization contribute records. Picked org units take priority over enrollment scope. A single current person or Rowseta role share automatically includes children of picked org units unless that setting was chosen by hand. With enrollment scope alone, children are off automatically and can be turned on. Empty resolved scope means no rows; it never means every org unit.

Column visibility chooses the report output columns. An unset or empty column selection means all columns. Personal data hidden replaces personal values with Hidden based on their source fields as well as recognised personal output names. Renaming a personal field, such as FirstName AS fn, or using it in a calculation keeps it hidden. Columns whose source cannot be traced are hidden too. Review the coverage note and use Test as before relying on this setting. See Personal information.

Own records only

Own records only keeps rows whose UserId equals the person’s linked Brightspace user ID, within the resolved org unit or launch course scope. It is a match against that report column, not against their email, display name or report creator. Without a linked Brightspace user ID, it shows no rows. The report needs the columns required to apply its limits; an unsupported query can fail to load instead of producing results.

Brightspace launches and the course boundary

A validated Brightspace launch identifies a person within the Organization by the signed Brightspace issuer and subject identity. Email, display name and the Brightspace user ID used for report records do not find or merge that identity. Launches must use the Organization’s own verified registration, with its client ID, deployment and audience checked.

Brightspace roles map to bounded Rowseta roles: Instructor, TeachingAssistant, ContentDeveloper and Administrator map to Instructor; Learner maps to Student; other or unrecognised roles map to No Access. A role assigned explicitly through People survives later launches. The mapping never grants Owner or Admin. See the Brightspace role mapping and Brightspace launch users.

A launch-created person initially resolves only Analytics permissions. An authorized administrator must record a ceiling lift through People before Organization permissions can apply. Lifting that ceiling and lifting the course cap are separate checks.

In the full app, a launch session stays within its signed launch course unless the person meets every promotion condition: they are an unsuspended launch-created person, their effective role is the built-in Report Builder, Admin or Owner role, the role was explicitly assigned through People with the administrator assignment still recorded, and a ceiling lift is recorded whenever that role holds Organization permissions. Custom roles, Instructor, Student and No Access do not meet this rule. Rowseta rechecks promotion on each request. A qualifying person gets the same full-app role scope as someone signing in directly with that role; losing a condition restores the course cap. A learner-classified launch still cannot open the full app.

Embedded widgets, widget detail pages and the support view of a launch always keep the signed course cap, including for promoted people. They also apply their own metric, audience and name rules. Report share row limits do not control widget numbers; report column and personal column restrictions can still narrow them. Write SQL does not bypass widget share restrictions. See Metrics and preview and Names on widget details.

When access cannot be confirmed

Malformed scope or column settings cause access resolution to fail instead of granting all records. An unrecognised or empty row rule permits no rows. The older aggregate-only rule prevents the report from loading until a current row rule is chosen. If promotion cannot be confirmed in a real app session, the course cap stays in place; Test as refuses to show rows when its promotion check fails.

Use the report’s Who can see this panel for the saved audience and the chips above its results for your own limits. Use Test as a person for a specific person’s resolved report access. Widget lines in Test as are labelled estimates, so also review the widget’s Audience tab.