Content Governance

30 min

This is currently only available to Essential Cloud users.

Overview

The Content Governance Service “Nagging Service” has been developed to assist and support content governance of the knowledge held in Essential Cloud. The service allows you to engage your stakeholders, owners, and users to maintain and keep the data captured up to date. This ensures that you have relevant and current data to support decision making. It has been developed to assist you in maintaining data, making it easier to review content. The service now sends out reminders for when things such as Applications, Projects, Technology Products, Business Processes, etc, need reviewing. 

You can use the Content Policy Editor to create the policies that will send out review reminders. Reviews can be done before a review reminder is sent out, or once the review reminder has been sent out. The user can access the review dashboard to see which data they need to review, what has been escalated already, anything that has already been reviewed, and what is coming up for review. 

If a review is left too long by a user, you have the option to have an escalation email sent out to management who can either perform the review, make the original user carry out the review, or pass responsibility to a different user. 

You can also keep track of who is up to date with tasks, the top performing reviewers. Alongside this, you change who is responsible to perform the reviews to suit the needs of your organisation. E.g., a user has left the company or is going on holiday when the next review is due. This is done via role as we believe it is better to switch roles than to switch users on a policy.  

The service only sends a reminder when action is required, this can be set to daily, weekly, monthly, and annual reviews/reminders.  

There are 3 main aspects to Content Governance, these are: 

1. Configuration
2. Reviews/Content Update
3. Escalation 

 

 

Key Components

What makes up Content Governance?

The review process is split into four areas, the Content Policy Editor, Content Manager Dashboard, Content Review Dashboard, and the reminder email that is sent out when a review is overdue. You will use the Content Policy Editor to create and manage your policies, and the dashboards to keep up to date with reviews. When a review is overdue, the user will get the ‘nagging’ email, and continue to do so until the content has been reviewed. 

Setup

You will need to have the editors enabled for them to appear in your editor list. You can do this from the EDM Capture screen (EA Class > EA Support > Essential Viewer > Report > Editor. Then selecting the Content Editors and enabling each one.  

You can rename the Editors if you would like to. Update the Report Label slot to your preferred name, e.g. ‘Reviewer Dashboard’ and publish to the viewer to update it.  

You can also use the Viewer Configurator – accessed via the View Library > Support Tab. Once in the View, go to the ‘Set Portals’ panel, in the editor tab, ‘Add Editor’ and select the Content Editor and Dashboards from the menu.  

You will need to have roles and actors defined and linked/attached with the classes you want to review (applications, projects, technology products) for the nagging service to work. You should have those defined before you create a policy. For the service to work, you will need a user that is listed as a stakeholder of the content that needs reviewing, e.g., application/project/etc. You will also need to link the individual actor with the email they use for Essential otherwise their dashboard will appear empty, and they will not receive any reminder emails. You can do this by going to the ‘Individual Actor’ class and to make sure each user has the correct email.  

Note: We recommend that you make sure users have the appropriate security clearances before setting up a policy. They will need clearance to be able to edit any content that if data needed to complete a review is missing. If you have classes or instances; including applications, projects, technology products, that are classified, only users with the necessary clearances will be able to edit and complete the necessary fields. For more information on security classifications, see here. 

Defining your Actors and Roles

You can have as many actors and roles as you need and give actors as many roles as they are responsible for within your organisation. The main ones you need here are Individual Actor, Actor to Role Relationship, and Individual Business Role. We will start with the Individual Actor; this is who will be reviewing the data that the policy is set for.  

In the capture screen go to EA Class > Business Layer > Business Physical > Actor > Individual Actor. Select an actor or create a new one. You can start by filling out the Name (1) and Email Address (2) fields.  

Once completed, click ADD/NEW in the Roles Played by Actor slot (3). This is your Actor to Role Relationship.  

You can then add the Role Actor is Playing e.g., IT Owner or create a new role if you need to. This is the Individual Business Role, if you are creating a new one, scroll to the Role for Classes slot and search for the required class. For this example, that would be ‘Composite_Application_Provider’ but if the role were Project Manager, you would select ‘Project.’ 

We can see our Actor now has the roles they need to review data. NOTE: only users with the assigned roles will see the dashboards and be able to review/manage the data. 

Still in the capture screen, in the Individual Business Actor class, go to SYS_CONTENT_QUALITY_REVIEW_POLICY_OWNER. This defines who can be selected as a policy owner, i.e., who will be notified if there are any issues with the policy. Scroll down to Actors Playing this Role and add the necessary actors here.  

NOTE: If you have no policy owners defined, you will not be able to enable the policy in the Editor. 

Content Policy Editor

This is where you will create and manage your review policies. Each policy can only be set for a class. For example, your application policy will cover all applications, a project policy will cover all projects, etc. A Complete Policy looks like this:

This Editor allows you to setup review policies for users, in short; when a reminder for an incomplete review is sent to a user, and if necessary, is escalated to management until the review is complete.

Creating a Policy

NOTE: You will need the Repository Admin role to be able to set up and edit a policy. To do this, go to Configure > Repository Administration > Manage Repository Users. Select the user(s) that require the Repository Admin role, then select the Edit button. In the ‘Roles’ section, make sure the Repository Admin box is ticked. After users have the correct permissions, publish to the viewer to put the changes into effect.  

Choose the Governed Class you want to set up a review policy for (e.g., Application) search for the one you want in the list, click it then click Add.

Define the Default Content Editor. In this example the Application Editor. You will need the Editor to have an Anchor Class, this should be defined automatically for Configurable Editors, but for custom Editors you will have to define it manually.  

You can define the Editor Anchor Class in the Capture Tool. Navigate to Editors via EA Class > EA Support > Essential Viewer > Report > Configured Editor. You will need to go to Editor > Configured Editor if you are using Custom Editors. Select the editor you need and scroll to Report Anchor Class. For example, the Application Editor has ‘Application_Provider’ as its anchor. To show the anchored Editor, conduct a hard refresh on the browser (ctrl/cmd+shft+R).  

Next, select the required Dashboard Slots for your policy. These are categorised as ‘Must, Should, and Could, so you can say each application must have a Name and Delivery Model, and a review will be complete once an application has been confirmed as having these, as a minimum requirement. These are enumeration values, so can be customised to be called whatever you want (e.g., Mandatory, Optional, Possible) 

Note: The selected result fields are what is displayed in the dashboard table columns. E.g., for this policy, the available columns will be name, description, delivery model, and codebase status. You can display or hide these in the dashboard. 

 

Define how often the content needs reviewing, this can be as frequent as you need it to be.  

Select the role, this is who is responsible for the review and who will receive the overdue email reminder, for example an IT Application Owner. 

Define the relationship the user has with the application. In this case, whether they are a Stakeholder of the Application or Independent of the Application. If the application owner is independent of an application and you set the policy to ‘as a Stakeholder of the Application’ they will not receive an email notifying them that a review is required.  

The image below shows how a user can be both an IT Owner and Business Owner of an Application, or just an IT Owner. The IT Owner receives the nagging email when their application review is overdue. In this diagram, if the CTO is tied to the ‘Review Policy’ they will not receive a reminder email, as neither the CTO role nor Actor (Judy Proctor) are tied to an application. However, if the CTO is selected to be notified through an escalation email, they do not need to be directly tied to any Application and will receive the email that reviews are overdue. 

Set how often the send notification is sent. Currently, you can only receive an email notification that is sent either daily, weekly, monthly, or annually, depending on your own needs—these will occur on the ‘first’ of each, i.e., Weekly reminders will be sent on a Monday, monthly will be the first day of the month, and annually will be the first day of the year. Daily reminders are sent overnight. 

 Finally, set the policy owner. After selecting a user, make sure you click the green tick to confirm them as the policy owner, otherwise the editor will not let you enable the policy. This is the person in charge of the policy, and they are the one notified if there is an issue with the policy. This could be if the review reminder notification email is being sent to no one. You must have a policy owner defined to enable the policy.  

NOTE: If you cannot see the policy owner you would like to, refer to Defining your Actors and Roles.  

 

The basic review policy is now set up, and you can add the escalation policy if required. To set up an escalation policy, define by how long the original review must be overdue (e.g., 14 days). Like before, select the role and how they are tied to the instance. (e.g., Business Application Owner and Stakeholder of Application) and again the frequency of reminders they will receive if a review has not been completed by a user. Note that escalation only occurs x number of days after the original review is overdue. If an application were due to be reviewed every 30 days, and Escalation Level 1 was after 14 days, the recipient of the level one escalation email would get it 44 days after the last review. So, each escalation level adds to the previous number of days, rather than from the original time of last review. 

You can escalate a policy as many times as is required, with the higher points of contact (e.g., Team Leader à Management à CIO, etc.) being sent a notification email when a review has been outstanding for the stated period. 

You can also turn your Content Governance on/off using the Enable/Disable switch in the top left of the Policy Editor.  

The Nagging Service

We call this our nagging service because it allows you to send regular, automated email reminders to users for content that needs reviewing. Each email will display the areas (Content Type) the user is responsible for (See below). Each area—e.g., application, technology products, projects—is separated by content type, and the “Open in Dashboard” button will take you to the relevant dashboard to complete your reviews. We can see that the user has one pending review in the Reviewer Dashboard, but not any overdue. It will also show statistics for the Manager Dashboard, in this case zero overdue reviews but 120 assignment issues, meaning content may need reviewing but no one is being notified that it needs reviewing.  

Content Reviewer Dashboard

Users can access this directly from the ‘Open in Dashboard’ link in the reminder email or from the Editor list in your View Library or, depending on your setup, a Portal . In here you will find:  

1. The Option 1/Option 2 drop down menu will display your content types, allowing you to quickly switch between different content types, e.g., applications (1), technology products (2), projects (3), etc. 
2. Your total assigned reviews (for the related Class) 
3. The number of escalated reviews 
4. The number of instances (e.g., applications) that require review 
5. The number of reviews completed by the user 
6. A chart showing the status (Reviewed, Requires Review, Escalated and New) of your content—reviewed, requires review, or escalated 
7. Table showing instances that need reviewing in the selected class.  
8. Table displaying the status of the individual instances, in this case applications, that the user is the IT Application Owner for and is how you access the review menu. These are set using the result fields selected in the Policy Editor. 

For ‘Test App 6’ Name and Delivery Model are marked as “Must” so for this review to be marked as completed, these two fields must have data. The others are marked as “could” so some have data and others do not, but we can still select Mark as Reviewed as these other items are not essential. 

You can quickly access the relevant Class Editor by using the blue ‘Edit…’ button. In this example it shows “Edit Test App 6”. If content is missing any data that must be captured to be accepted and marked as reviewed, you can see what is missing and enter the required data in the Editor. 

Once an Instance has been marked as reviewed, the slot “system Content Quality Last Reviewed Datetime Iso8601” is updated and timestamped. You can view this in the Capture screen. 

Content Manager Dashboard

This looks similar to the review dashboard, but also displays the Top 10 Content Reviewers and allows you to ‘Reassign by Application’ (or another instance) or ‘Reassign by Person’ (role). This gives you quick access to reassign a review if a user is on holiday and a review is urgent, or if someone has recently left the company, and you need to. You can view the status of reviews, which users are up to date with their reviews, and manage who is responsible for performing the review.  

Ensure your users have appropriate classification clearance to edit the class instance they have been assigned 

1. Total assigned reviews 
2. Escalated reviews 
3. Requires review  
4. Reviewed policies 
5. Application status 
6. Top  reviewers—here you can see a summary of these user’s actions and if they are hitting performance goals, this displays up to the top 10 users. 
7. Manage by application/role. Here is where you can reassign a policy for a different user to review if the current reviewer is unable to carry it out, e.g., if they have left the organisation or are on holiday when the review is due to be carried out. 
8. To reassign by content, select ‘Reassign by (e.g.) Application.’ In the table that pops up, tick the reassign box. You have the option to completely reassign the content to one user or to reassign for that review period if you just need another user to temporarily take over the review.  
9. Table showing instances that need reviewing in the selected class.

How to Request an instance to be reviewed after it has been “marked as reviewed.” After selecting the content in the table, the “Request Review” button will be next to the “Mark as Reviewed” button. This is only a feature in the Content Manager Dashboard. 

Testing Your Policy

Please Note: content governance emails will be coming from ” [email protected]” You should ensure all persons to receive review emails has the email address whitelisted.

To test a policy—to make sure that a user is going to get the nagging email—we recommend changing the review date of the object/instance you are working with, to more than the number of days since the last review, or to more than the length of the policy or escalation is. Next, set the policy to send daily emails so that users will get an email as soon as possible, you will have to check that users have received the nagging email. The exact time of last review is not important the custom date just has to trigger the service, when set to daily this will happen overnight so results will have to be checked the next day. Just so you can make sure the correct users will get the reminder email, or an escalation email, and the policy has been set up correctly.  

Updated 19 December 2024