Contact Support

Help & Support

How Permissions Work in Campus Data

The most important thing to know is that Campus Data does not actually control permissions for the data item, unless the data items is uploaded to Campus Data. For example, if you upload a spreadsheet to Campus Data, then Campus Data controls the permissions for the spreadsheet.

However, for all content that's linked to - i.e. you enter a URL when publishing the data item - Campus Data cannot control permissions to the actual data item. Access control in that case is handled by the system in which the data item is stored.

  • If the data item is published in Tableau, the Tableau server controls access.
  • If the data item is published in SQL Server Reporting Services (SSRS), the SSRS server controls access.
  • If the data item is published in Microsoft PowerBI, the PowerBI service controls access.

So What's the Point of Setting Security in Campus Data For Linked Data Items If Campus Data Doesn't Control Access?

If configured the same way the source system is configured, Campus Data mimics the data item's actual security. Mirroring the source system's security makes it possible to:

  • Hide data items from search results if desired
  • Enables discoverability. This key features allows Campus Data to present items in a user's search results even if the user doesn't have access to the data item, and then prompt users to request access.

What Types of Permissions Can Be Set in Campus Data?

  • Members of Campus Data teams.
  • Members of Active Directory security groups.
  • Members of Active Directory security groups managed in Campus Data (called Team Groups).
  • MAUI Roles
  • Institutional Roles
  • Organization (Primary Org, Dept, SubDept)
  • HR Job Code or Title

See the Campus Data Publishing Guide for more information.

How Often Are User's Memberships in These Roles/Groups Updated?

Campus Data must pre-calculate who has rights to each data item, because security rights for an item can be extremely complicated. MAUI roles, AD membership, Institutional Roles, etc. Attempting to execute that calculation (should X user see Y item) in real time when a user is searching and accessing items would be WAY too slow. It would make Campus Data unusable if every time a user did a search, Campus Data had to figure out in real time if it should display each of 200 potential items in the user's results list.

This calculation takes place as part of a daily sync job for all security elements except one.

  • For AD Groups owned & managed by/in Campus Data, changes are recognized immediately.
  • For all other security elements - AD Groups not owned by Campus Data, Institutional Roles, MAUI Roles, etc. - changes are recognized as part of the daily sync
    • The exception to this rule is that whenever a data item owner inspects or updates the security for a data item, the security for that item is refreshed.

The daily sync begins at 7am because the job has to wait for the data warehouse refresh to finish (to pick up MAUI and HR data), The security sync typically finishes between 9:00 and 9:30, but occasionally, it can be as late as noon before Campus Data detects a security change made the previous day.

How Can I Make Sure a Data Item's Security is Updated Right Now?

  • Use Campus Data managed AD Groups (team groups) to give permission to data items.
  • Inspects / update the security for a data item for which you want the access list to be refreshed.

I'm Currently Using an AD Group I Did Not Create in Campus Data. Can I Manage It in Campus Data?

Yes. Contact the Campus Data team if you wish to migrate an AD group you created outside of Campus Data into Campus Data to be managed there.