Permissions & Security - Highspot

Updated 1 second ago

For data security, encryption, and credential storage information that applies across all connectors, see Data & Security - Enterprise Search Connectors.

Our approach to permissions

The connector requests the minimum set of permissions the Highspot APIs allow for its functionality, and only read-oriented access wherever the source APIs permit it.
The connector never writes to or modifies data in Highspot.
Credentials are stored encrypted and are never exposed in logs, search results, or the Simpplr UI after initial entry.
Where a Highspot capability (such as Impersonation) is broader than simple content read, this is called out explicitly in Understanding the credential scope below, together with the guardrails that apply.

Credential scope

Auth type: HTTP Basic Auth (Client Key + Client Secret)

Highspot API access must be enabled for your instance (typically by Highspot Support). The credentials you configure in Simpplr must allow the following:

Permission / capability	Why it's needed
Client Key and Client Secret (API Basic Auth)	Authenticate all read calls to list Spots, Items, users, and download Item content
API access enabled on the Highspot instance	Required before Client Key/Secret can call the Highspot REST API
Impersonation enabled on the API client (optional, recommended for Spot-level permissions)	Discover each user's Spot membership so search results can be trimmed to Spots that user can view in Highspot

A Highspot administrator (or Highspot Support, for API/Impersonation enablement) must grant these capabilities. If you cannot enable API access or Impersonation yourself, coordinate with Highspot Support before proceeding to setup.

Understanding the credential scope

Impersonation

Why it's required: Highspot does not expose a Spot member-list API. To enforce Spot-level permissions in search, the connector must call list-Spots as each active user (via Impersonation) to learn which Spots that user can view.

What the connector actually does with it: Read-only calls to list Spots visible to each user. The connector does not create, update, or delete Highspot content, and does not change user memberships.

Guardrails: Impersonation is used only to build Spot membership for permission sync and to discover Spots during content sync when Spot-level permissions are enabled. All connector activity is visible in the sync dashboard.

If not granted: Spot-level permissions cannot be enforced. The connector crawls only Spots visible to the API-key user, and indexed content is searchable by all Highspot-linked Enterprise Search users with access to this connector. Use Simpplr Audience settings to restrict discovery if needed.

Alternative permission models

This table demonstrates the difference between when Spot Level Permissions are enabled and disabled

	Spot-level permissions (recommended)	API-key scope only
Access granted	Spots (and their Items) each user can view in Highspot	Only Spots/Items visible to the user who owns the API Client Key
Search visibility	Results are enforced with user membership obtained from Spot membership	Indexed content visible to all users with connector access
Setup effort	Higher — Highspot Support must enable Impersonation; turn off Disable User Impersonation and enable document-level security in Simpplr	Lower — Client Key/Secret only
Maintenance	Permission sync refreshes users and Spot memberships on schedule	No per-user Spot membership mapping
Recommended for	Production use where Highspot Spot membership must be enforced in search	Evaluation or tenants where all indexed Highspot content may be broadly searchable

Configure Spot-level permissions during Setup - Highspot (Disable User Impersonation off, Enable document level security on).

Versions and editions supported

Supported: Cloud (SaaS) Highspot with REST API access. The API base URL is instance-specific (host and version path may vary per tenant).
Not supported: Deployments without Highspot REST API access enabled.

Permission design

How permissions work

Permissions from Highspot are read and enforced in Simpplr Enterprise Search when Spot-level permissions are enabled. Users only see Spots and Items they already have access to in Highspot.

User and Spot membership sync: Active (non-suspended) Highspot users are synced by the permission sync. When Spot-level permissions are enabled, each user's visible Spots are discovered via Impersonation and used for security trimming. When a user's Spot access changes in Highspot, the change is reflected in Simpplr after the next permission sync (and the next full sync for document ACLs as needed).
Item permission changes: Items inherit visibility from their parent Spot. There is no separate item-level share model in this connector. Spot membership changes that affect which Items a user can see are reconciled through permission sync and full sync (see latency below).
Public or shared links: Anonymous or public Highspot sharing links are not used as an access model. Only Spot membership (when Spot-level permissions are on) or the API-key crawl scope (when off) determines what is indexed and who can search it.
Access removal: When a user loses access to a Spot in Highspot, that Spot and its Items stop appearing in their Simpplr search results after the next relevant sync completes (see latency below).
When Spot-level permissions are off: Indexed content is treated as searchable for everyone with access to this connector. Use Audiences to scope who can discover Highspot results in Simpplr.