Privacy Functionalities in Campus Solutions

The General Data Protection Regulation (GDPR) is a hot topic at institutions for various stakeholders (including boardroom members) since it came into effect on the 25th of May 2018. With this article I want to give you an insight into the specific privacy functionalities of Campus Solutions and how you could use these functionalities to support your business processes with the GDPR in mind.

The main functionalities I want to discuss are:

  • DDA (Demographic Data Access).
  • ID Delete.
  • Page & Field configurator.
  • FERPA (Family Educational Rights and Privacy Act).
  • Agreement pages in Activity Guides.
  • Generate data report from the Fluid interface.

For demo purposes, I’ve created a Fluid Dashboard where I’ve bundled all the relevant links to the privacy tools and setup pages. To give you an idea, this is how the current version of my GDPR dashboards looks like:

Demographic Data Access (DDA)

This is not a new feature and commonly used by institutions to mask the birthdate and national ID fields in search/prompt records or the person details page. For each permission list you can define if the fields should be (partially)masked or fully displayed.

The default value is to mask both fields, this applies to each user. The result looks like this in a search result when searching for persons:

In the other example I’ve set up a specific permission list that also masks the field but by setting up the person detail screen to be only accessible with read-only security, these fields are also masked at the page itself:

With DDA you can make sure that the birthdate and national ID fields are only visible for specific users.

At the moment it is possible to add more fields by customization but it is probably better to wait for Oracle to deliver extra options. See future plans at the end of the blog post.

ID Delete

With this utility you can delete an EMPLID (in our example a student) and related records from the system. The first step is to establish the control records. If the EMPLID that is to be deleted is found in one of these records, it generates a warning and you’re not able to continue with deleting.

The provided control records cannot be removed but you can add your own control records. Also note the STDNT_CAREER record. This means that you cannot delete student data without removing the student from this control record. This can only be achieved by following the CS processes like removing results, enrollments, admissions records, etc. As in most cases, local laws dictate to keep certain student data. I see this feature to be mainly usable for non-admitted students.

Deleting the EMPLID itself with the utility is very straightforward. Enter the EMPLID (or multiple) and run the process.

A log is created to see which records have been updated.

Please note the following. This process does not delete an EMPLID from all of the records in CS, especially custom records. In the HCM update 26, the ID delete functionality has been improved and makes it possible to overrule control records, add your own records and set exceptions. Oracle has planned to implement these features in an upcoming CS update. See future plans at the end of the blog post.

Page & Field configurator

In PUM image 8, a new functionality is introduced called the Page & Field configurator. With this tool you can change almost every aspect of a PS page using a front-end utility. You are able to hide fields, modify labels, set default values, set fields as required and connect this to security (roles/users).

How does this work in our privacy story? Think about a scenario in which you want to hide certain person data fields on a page for specific users. As not everybody may need to access all kind of personal data but you don’t want to do major customizations or create specific pages for users with limited fields.

In this example we hide the Gender and Marital status field and regional tab on the person page for a specific role.

  1. Here you select the fields that you want to configure. In this example we selected the MAR_STATUS and SEX field and set it to “Hide Field”.
  2. Here you set the page configurations. In this example we set the “Regional” page to not visible.

On the user list we define that users with the Role “CS – Admin DDA Display Only” will see these changes.

Then on the Map to Portal Registry tab we define through which navigational path this change should be visible. In this example users will only see the change if they open the person page when navigating using the menu options in the highlighted route.

Now when we compare the before and after:

You will see that the regional tab and both fields are not shown.

The Page & Field configurator is a very powerful tool and we only scratched the surface with this example. As you can setup multiple configurations for each component for different users, navigational paths and even use criteria to only apply this change in certain situations the possibilities are almost endless.


This functionality is not so well known in Europe as this feature is designed specifically for the US market. FERPA is an acronym for “Family Educational Rights and Privacy Act” and is based on the US law with the same name. But as this functionality is flexible we can also use it for our (GDPR) purposes.

With the FERPA functionality the student is able to indicate for all kinds of personal data to restrict certain use by the institution. Next to that, the user can also set exceptions (when configured). It is also possible to let an administrator set this for a student. By default most of the personal fields are added to the FERPA configuration but you are also able to add your own custom fields to it.

In the following scenario a student is going to limit the use of his campus e-mail address for the institutions’ internal publications only using the Fluid self-service.

When you navigate to the Profile page the “Privacy Restrictions” option is visible. In this setup the student is only allowed to set restrictions for e-mail:

Clicking on campus e-mail type reveals the detailed options:

We set it to restricted and give an exception for internal publication only. When saved it looks like this:

Then when navigating the administrative side on the specific FERPA pages where we can exactly see what is restricted you will see the following result:

We can also see the FERPA results using the person page using the shade icon:

As there is no e-mail releasable this link is not shown.

But do we set the exception to internal publication only right? Yes, that is true but we cannot see the exceptions on these screens. We only know the student restricted the use of his e-mail and because there was only one e-mail registered, no other releasable e-mail address is shown. So what can we do with those exceptions then? As you can easily query on the FERPA restrictions you can make sure that processes, BI reports or other queries look at the restrictions plus exceptions and then determine to include or exclude certain data. There are also FERPA web services available so you can even think of synchronizing these restrictions with satellite applications, active directory, etc.

Agreement pages

One of the features of Activity Guides is that you are able to setup custom agreement pages. So in an example where a student completes his/her registration using an Activity Guide in Fluid you are able to add your own privacy agreement page. One of the nicest features of these agreements is that when the student confirms, the agreement is then stored like a digital signature. Let’s take a look.

First the setup of the agreement page:

You define the title, instruction text and the actual agreement text (1-3). Then with the agreement options you define the options for the student (4). With the save options you set the data you want to store when the student confirms (5).

When the student is then going through the actual guide the agreement page shows as one of the steps:

In this example the agreement is already accepted and the agreed date is visible.

A student is also able to review the agreements:

When clicking on an agreement a detailed page is shown:

From the administrative side you can also manage all of the agreements:

When clicking on the agreement you get a detailed overview:

When defining your own activity guide or using one of the delivered ones, you can very easily setup your own agreement page. Combined with the pre-delivered tools to manage and view the agreements I believe this is a good functionality that can help you manage a privacy and/or other agreement. At this moment you are able to setup a maximum of two agreement pages per activity guide.

Generate data report from the Fluid interface

There are two specific rights a student has, viewing the data you’ve gathered within your institution and to export this to a readable format. As an institution you might want to make this as simple as possible. In the following example I have approached this from the students perspective and let the student generate a report directly in self-service.

When clicking on the example Fluid tile:

A BI report with all the students` personal data is generated in PDF directly in the browser:

A small customization is needed to generate BI reports from a Fluid Tile and you need the actual BI report setup to make this possible. This solution is very flexible meaning you can have multiple tiles that link to different kind of reports or create a reporting page where the student can select which kind of report he/she wants to generate.

Future plans regarding Privacy Tools for CS

To conclude this article I want to give you some highlights about planned enhancements from Oracle regarding privacy tools.

  1. Oracle is going to deliver a list of all PII (personally identifiable information) fields, so that institutions are able to see which fields in which tables could contain personal data. Of course this is only based on standard functionality.
  2. The ID delete functionality is going to be expanded based on the HCM update 26.
  3. New Data Privacy Framework:
    • Phase 1 (2018): search and identify PII fields within PS.
    • Phase 2 (2019): hide, show or mask PII fields within PS (likely dependent on PT8.57).

At this stage there is no information on actual release dates and the planning might also be subjective of change.

Stay tuned for future updates on our blog regarding privacy in CS as we keep exploring and expanding the possibilities. With our knowledge and experience we can help you make Campus Solutions and your institution ready for GDPR. Don’t hesitate to contact our account manager, Wouter de Bruin ([email protected] / +31611417177), if you need assistance.


A HEUG advisory group dedicated to data privacy wrote an interesting whitepaper about data privacy in Oracle PeopleSoft and Cloud Products. As a HEUG member you can download this here.