KeySkope
KeySkope / Documentation
Documentation

Connections with
context.

What connectors collect, how syncs work and how to interpret the evidence.

How connectors work

A connector links an application to your KeySkope workspace and brings its account and access information into a shared view. This helps your team answer questions such as which accounts exist, which hold privileged access, and which may need review.

Each application exposes different information. KeySkope brings that evidence together, while keeping the source and its limitations relevant to the review.

Before you connect

Choose the application you want to review and involve an administrator who can authorise the connection. Check the connector guide for supported information, required permissions and any application subscription requirements.

  • Confirm the scope: identify the organisation or application environment you intend to connect.
  • Check access: ensure the account or credential used for setup has the permissions the connector requires.
  • Choose an owner: assign someone to maintain the connection if credentials expire, permissions change or the application administrator leaves.

Use your approved process to handle credentials. Keep secrets out of ordinary email, support tickets and screenshots.

Setting up the connection

Open Connectors in your workspace, select the application and follow its setup fields. Authentication varies by application: a connector may require an API credential or another supported authorisation method. Follow the requirements for that connector rather than assuming the same permissions work everywhere.

After saving the configuration, run a sync and review the result. A saved configuration alone does not confirm that information has been collected successfully. If the sync fails, check the connection details, granted permissions and the application's availability before trying again.

What information is collected?

The information available depends on the connector, the application's API and the permissions granted to the connection. Typical categories include:

  • Account details: names, email addresses or source identifiers used to distinguish accounts and relate them to identity information.
  • Account status: whether the source reports an account as enabled, disabled or another supported state.
  • Access information: available roles, permissions or memberships that describe an account's access.
  • Activity: supported sign-in or activity timestamps that help assess when access was last used.

These categories describe access evidence, not a promise that every connector supplies every field. For example, an application may expose administrator roles but no usable login history. Its access can still be reviewed even when activity is unavailable.

How syncs keep results current

Scheduled syncs refresh the information in KeySkope. Administrators can also run a sync from the Connectors page when they need to check a recent change or validate a repaired connection.

Results are a collected snapshot rather than a live view of every action inside an application. If a role changes or an account is disabled in the source, that change appears after a successful sync collects it. Source reporting delays can also affect when activity becomes available.

If a connection stops working, the information already shown should not be treated as proof of the application's current state. Check the latest sync result before making decisions that depend on fresh data.

How accounts relate to identities

An application account and a person are different things. One person may hold several accounts, while some accounts belong to a service, an external collaborator or a shared function. KeySkope uses available identity information to relate accounts where a match can be established.

An unmatched account needs investigation; it is not automatically unauthorised. An old email address, a missing identity record or a legitimate service account can explain a mismatch. Review the source account and its intended owner before deciding what should happen to it.

Reading the findings

  • Privileged access: access flagged by the source role or permission mapping. Investigate what the role permits and whether the account still needs it; privileged roles can carry different levels of authority.
  • Leavers with live access: accounts that remain enabled for identities marked inactive. Confirm the identity status and the account's current purpose with its owner.
  • Orphan or unknown accounts: accounts whose relationship to an identity needs review. Establish ownership and business purpose before taking action.
  • Stale access: access associated with old recorded activity under the displayed metric. Check the activity coverage and whether infrequent use is expected.

For example, an administrator account with old recorded activity may be unnecessary, or it may be an emergency account maintained for a specific purpose. The finding provides a starting point for a decision, rather than deciding for you.

Understanding activity and missing data

Activity does not mean the same thing in every application. A source may provide a last login, a broader activity timestamp or an observed sign-in through an identity provider. A sign-in through an identity provider does not establish everything a user did inside the application.

When reviewing a selected application, use the activity information for that application. Not recorded means no timestamp is available in the collected record; Unavailable means that measure is not supported by the source. Neither means an account has never been used.

Recent setup, collection gaps and source history limits can all affect the evidence available. Check the connector guide before using activity as the sole reason to remove access.

A practical review workflow

  1. Check collection: confirm that the connector has completed a successful sync.
  2. Choose a question: start with an application or a finding in Overview, such as privileged or stale access.
  3. Inspect the accounts: use Access explorer to review the account details, roles and available activity.
  4. Confirm the context: check ownership, business need and any missing evidence with the application owner.
  5. Follow up: make approved access changes in the source application's administration tools, then sync again to review the updated information.

Maintaining or disconnecting a connector

Your administrator controls the source permissions granted to the connection. Review those permissions when responsibilities change, and update the connector configuration when its credentials are rotated.

To stop further collection, revoke the connection's access in the source application. Revoking access does not itself delete the application's accounts, change their roles or erase information previously collected in KeySkope.

When something looks wrong

  • The connection fails: check for expired credentials, missing permissions or an incorrect application environment.
  • Accounts are missing: confirm the scope and coverage of the connector. A connector for console administrators may cover a different population from the application's end users.
  • A role change has not appeared: verify it in the source, then check whether a successful sync has run since the change.
  • Activity is blank: check whether the application supplies that measure and whether the collected account has a recorded value.
  • Totals differ between views: check the selected filters and whether the figures count accounts, identities or access records.

If you need help, include the application name, the time of the attempted sync and the visible error message. Do not include API secrets or passwords.

Explore connector guides for application-specific coverage and requirements, review guides for practical checklists, and Security for workspace protections.

A clearer place to start

Know your access.
Focus your next review.