People interact with the Common Web Platform (CWP) in different roles and with different responsibilities. Certain actions, such as incurring costs, or making technical changes, can only be carried out by people in specific roles. This ensures the integrity of the platform.
This section outlines the various roles and the responsibilities of each. It also explains which roles are authorised to create users, and how this is done. Roles and responsiblities are detailed here.
Authorisation requests are sent to one role only, starting with the Release Manager. If a role is not assigned, or does not respond to a request within a reasonable timeframe (ninety minutes for deployments), we have an escalation path in place to make sure a response can be obtained:
Certain roles allow backup nomination via the appropriate Service Desk ticket. Escalation to backup will occur if the primary manager is temporarily not available. See the backup roles description for more details.
Non-trivial requests that come at a financial cost or pose an outage risk to the production environment will use SMS communication to obtain approval. Such requests may include adding or removing a stack, changing Disaster Recovery level, updating file permissions, or low-level upgrades to the LAMP stack. A full list of these high-impact actions are listed below.
When a request requires SMS approval, the CWP team at SilverStripe will send a text message, from a constant phone number, to the person(s) authorised to approve the request. Depending on the nature of the request, the recipients may include the Stack Manager, Relationship Manager, Release Manager, Backup Stack Manager, or Backup Release Manager. The text message will briefly describe the change that is about to be applied, along with two distinct text options for reply: one to approve the change, and one to deny it. Once the CWP team receives a valid response, the process to handle the request will either continue or be cancelled. If no response is received, the request remains open, and it is the responsibility of whoever initiated the request to obtain approval from the authorised person(s).
Using two-factor confirmation with SMS adds an extra layer of protection to your website by mitigating any chance of a single-access control (e.g. a password) being compromised and causing major damage. The SMS controls ensure that whoever is authorising the change is not only authenticated, but is also in possession of, and can access, a known mobile device. Alternatively, email also provides decent two-factor confirmation, but because SMS is received on a single device that is likely locked and concealed on its owner, text messages are considered far more secure.
There are a few other benefits to using SMS controls. All SMS exchanges are recorded, which provides an audit trail if and when faults arise. Further, SMS approvals are greatly expedited compared to their analog counterparts, as they require no signed documents, and responses can be automated.
The following table can accessed by tabbing through its content and is available to screen readers.
| General | Relationship Manager* | Stack Manager | Release Manager | Deployer | Developer | Team Member |
|---|---|---|---|---|---|---|
| Bug report | Can do | Can do | Can do | Can do | Can do | Can do |
| General support request | Can do | Can do | Can do | Can do | Can do | Can do |
| Request Code Review or Code Warranty | Can request and approve via txt | Can request and approve via txt | Can request, but requires approval | Can request, but requires approval | Can request, but requires approval | Can request, but requires approval |
| Service issue / Outage report | Can do | Can do | Can do | Can do | Can do | Can do |
| Stack actions | Relationship Manager* | Stack Manager | Release Manager | Deployer | Developer | Team Member |
| Add additional test environment | Can request and approve via txt | Can request and approve via txt | Can request, but requires approval | Can request, but requires approval | Can request, but requires approval | Cannot execute |
| Add Premium WAF | Can request and approve via txt | Can request, but requires approval | Can request, but requires approval | Can request, but requires approval | Can request, but requires approval | Cannot execute |
| Remove domain names associated with an Instance | Can do | Can do | Can do | Can do | Cannot execute | Cannot execute |
| Add domain names associated with an Instance | Can do | Can do | Can do | Can do | Cannot execute | Cannot execute |
| Alter size or Disaster Recovery level | Can request and approve via txt | Can request and approve via txt | Can request, but requires approval | Can request, but requires approval | Can request, but requires approval | Cannot execute |
| Delete Instance | Can request and approve via txt | Can request and approve via txt | Can request, but requires approval | Can request, but requires approval | Can request, but requires approval | Cannot execute |
| Request new Instance | Can request and approve via txt | Can request, but requires approval | Can request, but requires approval | Can request, but requires approval | Can request, but requires approval | Cannot execute |
| Access system logs (prod) | Can do | Can do | Can do | Can do | Cannot execute | Cannot execute |
| Access system logs (non-prod) | Can do | Can do | Can do | Can do | Can do | Cannot execute |
| Add and alter an Instance repository | Can do | Can do | Can do | Can do | Can do | Cannot execute |
| User management | Relationship Manager* | Stack Manager | Release Manager | Deployer | Developer | Team Member |
| Changing Relationship Manager | Can request and approve via txt | Cannot execute | Cannot execute | Cannot execute | Cannot execute | Cannot execute |
| Adding, removing or updating Stack Managers | Can request and approve via txt | Can request and approve via txt | Cannot execute | Cannot execute | Cannot execute | Cannot execute |
| Portal (this site) | Relationship Manager* | Stack Manager | Release Manager | Deployer | Developer | Team Member |
| Log in | Can do | Can do | Can do | Can do | Can do | Can do |
| Access instance information | Can do | Can do | Can do | Can do | Can do | Can do |
| Dashboard | Relationship Manager* | Stack Manager | Release Manager | Deployer | Developer | Team Member |
| Log in | Can do | Can do | Can do | Can do | Can do | Cannot execute |
| Deploy to UAT/test | Can do | Can do | Can do | Can do | Can do | Cannot execute |
| Deployment to production with approval | Can do | Can do | Can do | Can do | Can do | Cannot execute |
| Direct deploy to production (emergency) | Can do | Can do | Can do | Can do | Cannot execute | Cannot execute |
| Prod data snapshots | Can do | Can do | Can do | Can do | Cannot execute | Cannot execute |
| Other data snapshots | Can do | Can do | Can do | Can do | Can do | Cannot execute |
| Adding, removing or updating roles | Can do | Can do | Cannot execute | Cannot execute | Cannot execute | Cannot execute |
| Updating own personal details | Can do | Can do | Can do | Can do | Can do | Can do |
| Temporary administrative access to the CMS | Can do | Can do | Can do | Can do | Cannot execute | Cannot execute |
| GitLab | Relationship Manager* | Stack Manager | Release Manager | Deployer | Developer | Team Member |
| Log in | Can do | Can do | Can do | Can do | Can do | Cannot execute |
| Server configuration | Relationship Manager* | Stack Manager | Release Manager | Deployer | Developer | Team Member |
| Add and remove IP Addresses on an stack whitelist | Can do | Can do | Can do | Can do | Cannot execute | Cannot execute |
*) Backups are available for Relationship Managers. See "Backup roles" section.
Last modified:
