Help Center

Menu

Squiz Search custom roles in Squiz DXP

Within the Squiz DXP ecosystem, you can govern search administration using a granular, custom-role model. This Role-Based Access Control (RBAC) framework partitions access with precision. This system ensures that search administration aligns with specific internal business processes.

Why use custom roles?

In complex enterprise environments, a uniform permission structure often leads to over-privileged users. Custom roles provide high-fidelity governance where users only have access to the necessary resources and tools.

Common scenarios for custom roles include:

Divergent environment needs

Aligning access based on the development lifecycle, for example, different permissions for "Development" versus "Production".

Sub-setting resource access

Restricting users to a specific subset of resources, such as search packages or data sources relevant only to their department.

Fine-tuning responsibility levels

Adjusting the scope of a common persona to have more or less responsibility than the default DXP mappings allow.

Separation of concerns

Governing access by separating the permission sets (what a user can do) from the resources (which collections they can access). This ensures that the same resource permissions can be assigned to multiple users while maintaining individual functional access levels.

Activation framework and tenancy impact

Squiz Customer Success manages the activation of custom roles at the DXP tenancy level.

Upon activation, all roles except for the DXP Owner lose default access to Search. You must activate Custom Roles in your tenancy before you can configure them in the Search Administration Dashboard.

As a result, users (except Owners) will lose access while you configure the new roles.

To minimize disruption, we recommend the following workflow:

  1. Activate Custom Roles.

  2. Assign all users to the default custom role that mimics their previous access.

  3. Configure your new detailed Custom Roles.

  4. Re-assign users to the new Custom Roles.

Additionally, existing users will not appear in the search administration dashboard until they log in for the first time after activation.

Read the Troubleshooting and known issues section for a manual synchronization workaround.

Access state comparison

Feature Custom roles: Not activated Custom roles: Activated

Governance basis

Governed strictly by the assigned DXP role.

Governed by manual assignment within Search.

DXP Owner access

Full access.

Full access, including user and role management.

Other DXP roles

Map to default search roles.

No access until assigned a default or custom role.

Configuration and onboarding workflow

User management utilizes a two-step authorization flow. Identity is managed in the DXP Console, while specific search authorization is handled within Search.

Onboarding process

  1. Invite the user through the DXP Administration tile in the DXP Console and assign a base DXP role.

  2. Access the search Administration Dashboard and select the Manage Users tab.

  3. Locate the user:

    1. Search by email if the user has been invited but has not yet accepted.

    2. Search by name once the user has accepted the invite and logged in.

  4. Assign the relevant custom or default roles within the search profile of the user.

Creating a custom role

To create a custom role within the search Administration Dashboard:

  1. Navigate to Administration  Users & roles  Manage roles.

  2. Click Create role.

  3. Enter a unique role name.

  4. Select the granular permissions required for this role.

    Use the DXP role toggles, for example, "DXP Content Editor", to inherit base permissions from standard DXP roles.

  5. Specify which resources, such as search packages and collections, this role can access.

  6. Click Save.

Role architecture and best practices

To simplify permission management and ensure a flexible governance model, follow these architectural best practices.

Separate permissions and resources

Assign at least two roles to each user to separate functional permissions from resource access:

Resource role

Defines the set of resources available, such as specific search packages, collections, and data sources.

Permissions role

Defines the functional capabilities, such as access to analytics, reporting, or configuration tools.

Layering these roles allows you to assign the same resource access to an entire department while fine-tuning individual functional responsibilities.

Use system roles

Leverage built-in system roles to streamline configuration:

client~primary

Include this role in your application token configuration to enable it to inherit core system access.

client~owner-resources

Assign this role to a custom role to grant access to all collections within the tenancy. This removes the need to manually maintain a list of collections in a custom resources role. Assign the custom role to any users who require this level of access.

Technical considerations and guardrails

To ensure server stability and consistent behavior in the Squiz DXP environment, adhere to the following technical guardrails.

Additive permission model

Search utilizes an additive permission model. Once a permission is granted through any assigned role, it cannot be revoked by another role.

If you need to create a role that is similar to an existing one but with fewer permissions, you cannot inherit from the existing role. Instead, you must create a new role and manually select only the required permissions.

Range restrictions

Certain roles, such as the default dxp~developer role, include range restrictions on configuration keys to prevent performance degradation or security issues. If you are creating a custom role to replace a default developer role, ensure you replicate any necessary range restrictions to maintain server stability.

Technical guardrails and multi-tenant safety

In the shared Squiz DXP cloud environment, certain permissions and configurations are restricted to ensure server stability, data privacy, and alignment with DXP Console management.

Prohibited permissions

The following permissions are unavailable for selection when creating or editing custom roles.

Security risks (Groovy scripts)

Scripts can execute arbitrary code on the server and are prohibited:

  • sec.custom-gather

  • sec.delete.collection.disable-hook

  • sec.hook-script

  • sec.workflow-config

Data privacy and exposure

Permissions that could expose cross-tenant data or internal server diagnostics:

  • cp.diagnostics

  • sec.administer.read

DXP Console-managed

Functions handled exclusively by the DXP Console for centralized administration:

  • cp.change.passwd

  • sec.accounts.create-users

  • sec.accounts.delete-users

Deprecated or replaced

Legacy permissions replaced by native DXP tools or modern protocols:

  • plugin.show.fm.rules (replaced by WebDAV)

  • sec.sched.cron (replaced by Task Scheduler)

  • sec.queue.priority

  • sec.service.mediator

Restricted configurations

The following configuration keys cannot be modified within search packages or result pages.

Multi-tenant performance

Settings that impact server-wide resources or shared services:

  • auto-completion.source.extra

  • crawler.frontier_* (including hosts, port, num_top_level_dirs, use_ip_mapping)

  • crawler.max_individual_frontier_size

  • crawler.robotAgent

  • index.target

  • push.auto-start

  • push.run

  • push.initial-mode

  • push.replication. (including master.hostname, master.push-api.port, ignore.)

  • push.commit.index.parallel.*

  • push.merge.index.parallel.*

  • push.replication.ignore.*

  • push.scheduler.*

Server-wide administration

Legacy internal settings or those managed at the DXP infrastructure level:

  • crawler.classes.* (including Frontier, Policy, URLStore, statistics)

  • crawler_binaries

  • query_processor

  • scheduler.paused

  • ui_cache_link

Performance and caching

Settings with significant impact on server stability and response times:

  • crawler.cache.* (including DNSCache, LRUCache, URLCache)

  • ui_cache_disabled

  • filter.document_fixer.timeout_ms

  • trim.filter_timeout

  • trim.threads

  • trim.request_delay

  • trim.max_size

  • trim.store_class

  • trim.web_server_work_path

  • ui.modern.external_num_ranks_limit

User lifecycle management

The Search user account is linked to the DXP user account. Actions performed on a DXP user account directly impact their Search access and profile.

Disabling DXP users

When you disable an active DXP user, their Search user account is automatically deleted. This ensures that access remains synchronized with the DXP account status.

Re-enabling DXP users

When you re-enable a DXP user, a new Search user account is automatically created. The access level of the re-enabled user depends on their DXP primary role:

DXP Owner

Access to search capabilities is automatically applied.

Other DXP roles

The user will have no access to search capabilities until an administrator adds them to a custom or default role in Search.

Collection creation behavior

When custom roles are enabled, the system manages access to newly created collections automatically but requires manual follow-up for broader distribution.

Automatic assignment

When a user creates a collection, it is automatically added to:

  • The personal profile of the creator.

  • The system-level owner-resources role.

Manual distribution

To grant other users or roles access to the new collection, a DXP Owner or a user with role management permissions must manually add the collection to the relevant custom resource roles.

Use these configurations to streamline administration and enhance security in complex environments.

Restrict collection creation

In organizations with strict governance requirements, restrict the ability to create collections to a specific group of technical administrators. This ensures that new resources are created according to internal standards and properly assigned to resource roles immediately.

Squiz staff role

For Squiz personnel or high-level technical administrators, create a dedicated "Squiz-staff" role that combines comprehensive management capabilities. Configure the role to include:

  • The standard dxp~developer role for technical tools.

  • The client~owner-resources role for full collection access.

  • Explicit permissions for user and role management.

Administrative UI behavior

Understand these UI behaviors to correctly interpret the search administration interface.

Feature visibility and commit access

Depending on their assigned roles, users might temporarily appear to have access to certain features in the UI. However, if their role does not explicitly permit the action, the system will prevent them from committing the final step or saving changes.

Permission scoping

Permissions within Search are scoped at the client/user pair level. Authorization is not globally applied to a user account but is specifically defined for each search client (tenancy) they access within the DXP.

Troubleshooting and known issues

Visibility of invited users

Users appear in the Manage Users list as soon as they are invited in the DXP Console. If they have not accepted the invite, they appear by their email address. Once they accept, their full name details (as set by the user) will appear.

Visibility of pre-activation users

Users who existed before custom roles will not appear in the search list until they log in to Search for the first time.

To force them to appear immediately, a DXP Owner can open the user’s record in the DXP Console and click Save without editing anything.

Owner demotion

If you demote a user from the DXP Owner role, they lose all search access immediately and must be manually assigned a role.