The user access settings described below do not apply to tranasctional or relationship surveys, or to the Compliments, Complaints & Suggestions form. Customers are free to enter surveys and complete the CCS form with no restrictions.
Introduction
There are four reasons for accessing CIOPulse
- Completing a survey.
- Viewing information (User Access).
- Using the Portal for administration (Portal Access).
- Using the API (API Access).
Anyone with a survey URL can complete a survey. This article describes the security rules for User Access, Portal Access and API Access.
We'll start by describing the options available to you to control User Access. Then we'll describe Portal Access and API Access.
- Viewing displays, reports and dashboards - User Access Security
- Administering CIOPulse with the Portal - Portal Access Security
- Updating or retrieving data with the API - API Access Security
If you want to jump straight to a particular security setting, use these links.
User Access Security
There are various options for controlling user access. These options are all managed in the Security section of your Instance Preferences in the Portal.
Let's describe each of these five options.
1. User Login Type
There are five options available under User Login Type:
No login required. Anyone who has the correct URL can access the displays, reports and dashboards.
Email Address. Before accessing any display, report or dashboard, the user is asked to enter their email address. Provided this email address exists in the Portal, a verification code will be emailed to it. Once the verification code has been successfully entered, access is granted.
Single Sign-On. Before accessing any display, report or dashboard, the user is directed to your Identity Management System for SAML-based authentication. Once authenticated by your system, and provided this email address exists in the Portal, access is granted.
Before Single Sign-On can be selected, our security team and your security team need to exchange SSO metadata as described in this article.
Access Code - All. Before accessing any display, report or dashboard, the user is prompted to enter a shared Access Code.
Access Code - Management. Before accessing any dashboard or the monthly management report, the user is prompted to enter a shared Access Code.
Access Codes must be at least 14 characters long and can contain spaces. Why? A complex 8 character password can be cracked by brute force in a week. But a simple 14 character passphrase would take two years to crack!
For Email Address security, the user will remain signed-on until either the browser is closed, or until there's been no activity for between 60 and 90 minutes. For Single Sign-On, your Identity Provider controls the length of the authenticated session.
If you use Single Sign-On or Email Address security, you can provide your users with access to a launchpad screen where they can access common displays, reports and dashboards. See here for more info.
2. Restrict Access by Role
Restrict Access by Role is a simple Yes/No setting. It can only be set to 'Yes 'when User Login Type is Email Address or Single Sign-On.
When set to Yes, Support Leads are only able to access displays, reports and dashboards for their Support Group(s).
The Authority granted to the Also Alerts of Support Groups is determined by the 'Also Alerts for SR Only' setting (see below).
When Restrict Access by Role is set to 'Yes', the only people authorised to access all data, regardless of Support Group are:
- Master & Supporting Administrators.
- Anyone whose email address is in your 'Monthly Report Recipients' list (in the Email Recipients section of your Instance Preferences).
- Anyone whose email address is in your 'Additional Send To Recipients' list (in the Email Recipients section of your Instance Preferences).
3. Also Alerts for SR* Only
(*SR = Service Recovery)
Also Alerts for SR Only is a simple Yes/No setting.
When set to 'No':
- Also Alerts for a Support Group will get emailed the same daily, weekly and monthly automated reports that the Support Lead does.
- When 'Restrict Access by Role' is 'Yes', Also Alerts will have the same access rights as Support Leads. Also Alerts for a Support Group are able to access displays, reports and dashboards for their Support Group(s).
When set to 'Yes':
- Also Alerts will get emailed the daily Service Recovery Report (and SMS) when the Support Lead does, but will not get weekly or monthly automated reports.
- When 'Restrict Access by Role' = 'Yes', Also Alerts will only be able to access Service Recovery Notes for their Support Group(s). Also Alerts for a Support Group will not be able to access any other displays, reports or dashboards for their Support Group(s).
4. Encoded URLs Only
Encoded URLs Only is a simple Yes/No setting.
CIOPulse has the ability to obscure the URLs used to access displays, reports and information, by converting all the parameters in the URL into a single "id=" parameter. For example, a URL like this:
https://app.cio-pulse.com/survey-responses-nps?cpc=ABC123&rgid=SDESK
... can be converted into an encoded URL like this:
https://app.cio-pulse.com/survey-responses-nps?id=PeC7dih66das1r312351iksHs6jvM7YMHbqRbXabq3P3124
When URLs are encoded, the URL won't work if it is edited. This prevents a user from editing the URL in order to access different data, e.g. by changing the Support Group specified in the URL from &rgid=SDESK to &rgid=APPS.
When Encoded URLs Only is set to Yes, only encoded URLs can be used to access CIOPulse information.
To encode a URL, add &encode to the end of the unencoded URL. This will display the encoded URL that can then be used or shared. For example, entering this URL (with "&encode" on the end)...
https://app.cio-pulse.com/survey-responses-nps?cpc=ABC123&rgid=SDESK&encode
... will display the encoded version of the URL:
Administrators can encode any normal URLs by adding &encode to the end of an unencoded URL. All users can get a list of their encoded URLs by using the Send My Links or Launchpad functions.
When Encoded URLs Only is set to Yes, signed-in Administrator's can still access normal, unencoded URLs. This enables them to encode URLs with the &encode parameter.
5. IP Address Ranges
The IP Address Ranges field can be used to restrict access to CIOPulse to a given set of IP addresses. To do this, enter a comma-separated list of IP addresses or IP address ranges (with no spaces before or after the commas or anywhere else in the field).
Single IP addresses must be specified as an IPv4 address, e.g. 1.2.3.4
IP address ranges can be specified in any of these formats, or combination of formats:
- Hyphenated range:
1.2.3.0-1.2.3.255 - Wildcard format:
1.2.3.* - CIDR notation:
1.2.3.4/24or1.2.3.4/255.255.255.0
The IP Address Ranges field may contain a single IP address, a single IP address range, or any combination of both in a comma-separated list.
For example, if your IP Address Ranges field contained:
1.2.3.4,5.6.7.8-5.6.7.88,7.8.9.*,10.20.100.0/22This would allow anyone to access CIOPulse from an IP address of:
- 1.2.3.4, or
- between 5.6.7.8 and 5.6.7.88, or
- any IP address starting with 7.8.9., or
- any IP address between 10.20.100.0 and 10.20.103.255
Be very careful when using the IP Address Ranges field.
From the moment you save your changes, any device that falls outside of the IP address range(s) specified in this field will no longer be able to access any CIOPulse information.
IP Address Ranges do not restrict anyone from completing a CIOPulse survey, or using the Compliment, Complaint or Suggestion form.
To prevent you from not being able to access any CIOPulse information yourself, any range you specify in this field must include your current IP address. However, because Portal access is password-protected, you may login to the Portal from any IP address, not just those within the IP Address Ranges.
CIDR notation is an efficient way of expressing IP address ranges. It is complex though. We recommend you seek the advice of a network expert before using CIDR. You can convert IP address ranges to/from CIDR format using this handy resource.
If you use the IP Address Ranges field, users will not be able to access CIOPulse while away from the office and using their own IP address. To ensure access to CIOPulse while out of the office, your users must use a VPN whose IP addresses are included in your IP Address Ranges.
Do not enter any spaces before or after the commas or anywhere else in the field. There must be no spaces in this field or you will get an error message.
Like all websites, CIOPulse gets hit by unwanted bots spamming our server. When we identify bogus requests coming from a particular IP address, we block it. If one of your users tries to access CIOPulse from one of these blocked IP addresses (typically because they are using the same VPN as one of the bots we've blocked), they will be unable to do so.
Using Multiple Security Settings
Multiple security settings can be used at the same time. For example, you could specify IP Address Ranges and set 'Encoded URLs Only' to 'Yes'. This would only allow users to access CIOPulse from one of the in-range IP addresses and only when using an encoded URL.
The diagram below shows how each security setting provides optional layers of security:
Information Access by Security Setting
The table below shows what information users can access, depending on their role in CIOPulse and on your Security Settings:
| Restrict Access by Role = No |
Restrict Access by Role = Yes |
|||
|---|---|---|---|---|
| Also Alerts for SR Only = No |
Also Alerts for SR Only = Yes |
Also Alerts for SR Only = No |
Also Alerts for SR Only = Yes |
|
| No Login Required | Anyone with the right URL can view all displays and dashboards and the monthly management report. Other reports can be requested by anyone and emailed to any authorised report recipient* |
|||
| Email Address | Any logged-on Administrator, Send-To Recipient, Monthly Report Recipient or Contact can view all displays and dashboards and the monthly management report. Other reports can be requested by anyone who is logged-on and emailed to any authorised report recipient* |
Any logged-on Administrator, Send-To Recipient, or Monthly Report Recipient can view all displays and dashboards and the monthly management report. Support Leads and Also Alerts can only view displays and dashboards for their Support Group(s). Other reports can be requested by any authorised report recipient* and emailed to any authorised report recipient* |
Any logged-on Administrator, Send-To Recipient, or Monthly Report Recipient can view all displays and dashboards and the monthly management report. Support Leads can only view displays and dashboards for their Support Group(s). Also Alerts can access Service Recovery Notes for their Support Group(s). Other reports can be requested by any authorised report recipient* and emailed to any authorised report recipient* |
|
| Single Sign-On | ||||
| Access Code - All | Anyone with the Access Code can view all displays and dashboards and the monthly management report. Other reports can be requested by anyone with the Access Code, but will be emailed to the authorised report recipient* |
|||
| Access Code - Management | Anyone can view all displays. Anyone with the Access Code can view all dashboards and the monthly management report. Other reports can be requested by anyone, but will be emailed to the authorised report recipient* |
|||
| *Who can be specified in the &sendto= parameter of the Survey Responses report: |
Administrator, Send-To Recipient, Monthly Report Recipient, Support Lead or Also Alert for a Support Group |
Administrator, Send-To Recipient, Monthly Report Recipient, Support Lead for a Support Group |
Administrator, Send-To Recipient, Monthly Report Recipient, Support Lead or Also Alert for a Support Group |
Administrator, Send-To Recipient, Monthly Report Recipient, Support Lead for a Support Group |
Portal Access Security for Administrators
Administrators have their own email address and password for accessing the Portal. After successfully providing these credentials, a verification code is sent by SMS or email or via authentication app (such as Google Authenticator or Authy) to the administrator. Access is granted upon subsequent entry of this verification code
Portal access for Administrators bypasses all other forms of security described above.
API Access Security
Using our API requires an API Key that needs to be used when making API calls.
The API Key is available in your Instance Preferences in the Portal.
If you have IP Address Range security turned on, you must ensure the system making the API calls is doing so from an IP address covered by your IP address ranges. All other forms of security are bypassed.
