There are several different roles on the Common Web Platform (CWP). These roles are mostly held by agency staff, although some may also be held by vendors e.g. developers.

Depending on the structure of your agency, a person may hold one or more of the roles below.

We record people and their roles in a database of Service Desk user accounts. Our policy is that every user account maps to a person, with a name, email, and mobile phone. This ensures good security practice, allows us to readily contact people when we need to, and provides audit trails of who has carried out particular actions. For this reason we don't permit the use of accounts being shared by multiple people.

Sponsor

Each agency nominates a single sponsor, and this person’s name is written into the Participating Agency Agreement, a contract signed between the agency and SilverStripe. The Sponsor is the highest point of escalation at the agency. The Sponsor may be a CEO, CIO, head of communications, or other senior member. The Sponsor does not use the Service Desk.

Agency Relationship Manager

Each agency nominates a single Agency Relationship Manager, whose name is written into the Participating Agency Agreement. The Agency Relationship Manager is:

  • the primary contact at the agency for DIA and SilverStripe, in relation to the platform
  • a representative for the agency on the Operational Review Board
  • able to access reports and information about all Instances for the agency, through the Service Desk
  • able to determine which other people at an agency have access to the Service Desk
  • required to be readily contactable to approve new Instances
  • oversee the actions of one or more Instance Managers at an agency

It is up to an agency to decide the person to fill this role. An Agency Relationship Manager might be an IT manager, a communications manager or a digital channels manager.

For more information see matrix of roles and responsibilities.

Instance Manager

Each agency will have one or more Instance Managers. We use the term instance, because it can hold one or a collection of websites. Your Instance Manager is the business person responsible for a given Instance. One instance can only have one Instance Manager, but agencies can choose to have different Instance Managers for different Instances.

An agency’s Instance Manager might be called Product Manager or Site Manager. They are the person who looks after the website on a day to day basis, rather than producing technical or content services.

An Instance Manager is:

  • provided access to technical and financial information about a specific Instance, through the Service Desk
  • required to be readily contactable to approve work requests that have a cost (changing instance size, requesting code warranty)
  • required to be readily contactable to approve technical requests such as production deployments (if a Deployment Manager has not been nominated)
  • executing asset and database transfers to and from production via deploy.cwp.govt.nz (external link) (if a Deployment Manager has not been nominated)
  • Control access for CMS Administrators and Technical Staff for an Instance
  • responsible for sharing information they receive from the Service Desk, about releases, changes and outages, to whoever else needs to be made aware in  their agency or web services providers.   

An Agency Relationship Manager can create and remove Instance Managers, using the Service Desk.

For more information see matrix of roles and responsibilities.

Deployment Manager

An agency may wish to delegate technical responsibilities that an Instance Manager has, to a Deployment Manager. For example if the Instance Manager is a business representative and wants deployments to be managed by someone in their IT group.  Each instance can only have one Deployment Manager assigned. If no Deployment Manager has been nominated, then the Instance Manger manages these responsibilities.

The Deployment Manager will be contacted for relevant approval first, but if they are not contactable, the approval will be sent to the Instance Manager.

The deployment manager receives the same notifications as the Instance Manager. This includes information about outages, releases and changes.

The responsibilities of the Deployment Manager include:

  • approving deployments to production environments
  • executing asset and database transfers to and from production via deploy.cwp.govt.nz (external link)
  • removing domain names associated with an instance

For more information see matrix of roles and responsibilities.

Backup roles

Certain roles - Relationship Manager, Instance Manager and Deployment Manager - allow backup nomination via the appropriate Service Desk ticket. Escalation to backup will occur if the primary manager is temporarily not available.

Backup roles mirror the abilities of the primary roles described in the Access Matrix below (with one exception), and people holding them will be able to exercise the privileges without any further special approval nor activation. See the relevant role description to find out what actions are permitted. The only exception is that the backup cannot change its own primary role, nor revoke its permissions (e.g. Backup Instance Manager cannot change Instance Managers).

If a the primary role will not be available for a period of time, backup can be activated through the Service Desk's My Sites page.

Backup role activation screenshotThis will cause the escalation path to be adjusted to skip the primary and go straight to the backup. Backup can also be activated by the Service Desk staff upon discovering that the primary will not be available for a period of time.

Additionally, we will send all relevant comms to the backup roles as well, regardless of their activation status. This is because the backup roles can execute their privileges at any time and thus always need to be kept in a loop.

CMS Administrator

Your agency will have one or more CMS Administrators, with at least one for each Instance.

A CMS Administrator is:

  • given full access to the CMS Administration interface, including: controlling  access to the CMS and what privileges users have, configuring features such as analytics, social media and workflow.
  • able to make Service Desk requests and deployments, although such requests must then be approved by the relevant Instance Manager

The CMS Administrator is expected to have knowledge of administering websites and of the capabilities of the SilverStripe CMS. They might be a member of your agency’s web team, or your IT department.

An Instance Manager can create and remove CMS Administrators using the Service Desk.

For more information see matrix of roles and responsibilities.

Content Editors

Each agency will generally have a group of Content Editors. A Content Editor is:

  • given limited access to the CMS administration interface, for one or more websites
  • responsible for authoring and/or publishing content to websites. Whether they can publish depends on how an agency has setup its workflow.
  • able to make Service Desk requests and deployments, although such requests must be then approved by a relevant Instance Manager

A Content Editor is expected to have a knowledge of writing plain English content, which is structured for the web. They need to understand the web standards for preparing web content. They also need to be familiar with using SilverStripe CMS. A Content Editor does not need to be able to write HTML and CSS.

A CMS Administrator can create and remove a Content Editor, using the CMS. This includes being able to assign specific restrictions and privileges. For example, restricting authoring and publishing to specific parts of a website.

Technical Users (including Developers)

Each agency will have a variety of Technical Users working on an Instance. These are normally web developers, but could also be change managers or other technical staff.  Technical users may be vendors providing web services to an agency.

A Technical User is:

  • given access to the Shared Code Repository (GitLab (external link) (external link) ) and Deployment Tools (Deploynaut)
  • responsible for making templates and code changes (which define the appearance and functionality of a website)
  • able to request the transfer of code and data between environments and Instances
  • able to make Service Desk requests for a range of reasons, such as logging issues, asking for a code review or getting access to site logs. If requests incur cost then they must be approved by the Instance Manager

Technical Users will typically have strong website development skills, including familiarity with HTML, CSS, JavaScript, PHP, and databases. An exception may be where an agency has dedicated Change Managers, who may instead only make use of deployment tools.

An Instance Manager can create and remove Technical Users using the Service Desk.

For more information see matrix of roles and responsibilities.

Last modified: