Delegated administration best practices

Delegated administration makes it possible to distribute administration throughout an organization by restricting data access and granting role-based access in Medallia Admin Suite.

Managing sub-programs

Consider an example of a program spanning multiple divisions where a division difference exists in OCEM without an account. Assume the program is structured as follows:
  • Contact Center (CC) — A program where the Head of Contact Center is the owner since a significant portion of the customer's journey is handled by CC (sales through to support and renewal).

  • Retail — A program where the Head of Retail is the owner.

Three roles, as follows, would need to be established to independently change aspects of the programs.
  • CX Admin (Power user).

  • Contact Center CX Admin.

  • Retail CX Admin.

A CX Admin must always be included for the following reasons:
  • To ensure consistency across all sub-programs, a role needs to govern, audit, and set up policies to disable the administration of certain reports, surveys, etc.

  • To provide an omni-view that enables the user to understand the health of the company overall, including the health of each program and topline company-level metrics (such as NPS).

  • To ensure shared objects can never be managed by sub-program roles. For example, a sub-program admin cannot edit anything that the CX Admin can edit.

The following diagram demonstrates these three new roles as well as these guidelines:
  • For every sub-program that would require administration, create a CX [Program] Admin role.

  • One CX Admin role is required regardless of whether you provide access of this role to the client.

Administrative roles set up to manage two separate OCEM approaches within a program.

The following diagram demonstrates a market-based program: Administrative roles set up to manage two separate markets within a program.

Manage data and privacy

Admin roles may not have rights to view customer data. Work with your client team to determine if admin teams should have access to customer data. If there are concerns, data masking has to be used. Identify all Sensitive data and get approval from your account team on which roles can access which fields.

In more sensitive situations where management roles are not allowed any data scope, set up roles as follows:
  1. CX [Program] Management roles should have data access permissions set to SDLC segment of DEMO and UAT to ensure that no live data can be seen.

  2. Test users need to be built with safe data access permissions for CX [Program] Management role. This user will be assigned to each CX [Program] Management role User for preview, which can be set up in Advanced information for that specific role. This Test user would need access to every role that a CX Admin wants to administer so that previews in reports, for example, render specifically for that role.

You need a CX Admin for all roles that can see sensitive data and one for all roles that cannot. If you do not do this, then admins may themselves access to a role that can see sensitive data and be able to view information.

Roll out delegated administration

Most programs include 15-20 hours of effort where objects for administration (for example, surveys) are easy to identify for every admin. Work with a Solution architect if you have a complex program (see Multi-market programs below). To roll out delegated admin:

  • Identify how many admin roles and sub-programs are needed.

  • Elicit design for each admin role.

  • Deploy sandbox.

  • Configure admins.

  • Request that your customers use the sandbox to test the feature.

Multi-market programs: recommended phased feature roll-out

Multi-market roll-outs may require hundreds of hours since replication of administrable entities is required. For example, you may have a survey currently being used by two markets and need to split it into separate ones so that the admins for each respective market do not interfere with each other. Work with an architect to scope the effort.

The majority of what is available within Admin Suite should support delegated administration. This means that you can create separate admin roles to manage end user roles, surveys, and reports for their own respective ownership areas or sub-programs. However, launching all of Admin Suite in one phase requires a significant level of training and enablement and can be overwhelming for your customer. As such, a phased roll-out is recommended. Each sub-program can be thought of as its own implementation with the following stages:

Phase 1: Surveys, reports, mobile, and exports:

  • Communication (four weeks before pilot).

  • Design and build.

  • Kickoff.

  • Pilot period with training and high-touch support.

  • Launch.

Phase 2: Users and roles. It contains the same timeline guidelines as Phase 1.

Assumptions

  • For every feature to delegate, the program's entities are already separate. For example, for users, roles, and reports, roles for each program are already separated. For surveys, emails, and designs, programs are separate as are email templates and designs.

  • The work is billable because this is an upgrade, which delivers value to your program.

Guideline

  • Break up Medallia Admin Suite onboarding so that you choose feature sets that builds familiarity with Medallia.

Design delegated administration by features

Each administrative feature outlines corner cases and workarounds.

Note: Naming conventions are important. Prefix all objects with GLOBAL or the PROGRAM/MARKET name (such as [GLOBAL/PROGRAM/MARKET]_design_name). Do not rely on the In use feature because it significantly slows down your ability to identify objects when setting up the Admin role.

Feedback collection

  • Surveys — Recommend a survey per sub-program so that it is easier for admins to manage.

  • Designs — Prefix label all designs that will be visible to all roles as GLOBAL or the PROGRAM/MARKET name, such as [GLOBAL/PROGRAM/MARKET)]_design_name. This also enables Design rules.
    • Design rules — Driven off linkage to survey (by selecting the survey within the design rule). Recommend one design rule for every program. Any design rules conditioned with Event fields are visible to all roles that can manage designs. Prefix all designs visible to all roles as GLOBALLY SHARED.

  • Emails — Also enables Distribution settings, which are evaluated based on what emails are associated with a specific setting and in scope for the user. Any setting that is only based on a rule is visible for all users.

Translations

  • All admin roles that have access to manage translations can translate any entity in Experience Cloud.

  • Recommend central admin roles or sandbox/production process to merge changes.

Users

  • Permission by segment should be a subset of all users an admin has authority to edit.

Roles

  • If you grant a role (Role A) edit rights on an object (that is, a report), if that object has another role (Role B) attached to it, Role A must also have edit rights on Role B.

  • Administrative permissions:
    • As an admin, you can only delegate administration for administrative rights you have. For example, if you administer a role and have access to manage surveys, you can delegate Manage survey to all roles in your scope.

    • It is not possible to disable pass-on of administrative rights.

Data masking

  • K-fields are required to be explicitly masked if they access masked fields (for example, a field that accesses Full name (a_fullname) would need to be masked along with the System field).

  • Organization fields, such as Unit group, Unit name, Unit data fields, cannot be masked.

  • An admin role that cannot see sensitive data does not have the right to manage/create roles who have access to sensitive data.

  • If an admin role cannot access sensitive data and manage roles that need personable identifiable information, that user can create another user for themselves that allows them to view personable identifiable information if that user manages users who have roles allowing access to sensitive data.

Reports

  • Assuming that Preview users has been set up correctly, data appearing in a role's view is from predetermined and configured users. For example, all users in a role will see the same data regardless of their user access.

  • To manage reports, you must have access to all roles that can access the reports.

Exports

  • All admin roles that have access to manage exports can export any entity in Experience Cloud.

Unit and data access

  • Hierarchy access for admins where a user who has access to all Units and Segment sees all Units when managing the user but only Segment data in reports.
  • Consider multi-hierarchy implications.

Sandbox

  • Would multi-markets share one sandbox?
  • Who owns refreshing the sandbox and how would that impact many different admin teams?

UX

  • If you have access to two admin roles, switching between those roles requires logging out of Admin Suite. Only administrative permission for roles that are the user's primary role are supported. In other words, you need one role with superset access set up or two different user accounts with the primary role assigned accordingly.

Other products

  • Any users with abilities to manage features in Digital Feedback, Medallia Conversations, and Medallia Text Analytics via Admin Suite can access all programs/scope within that feature.

Delegated administration worksheet

Delegated administration worksheet.