Product knowledge

Docs

Getting started
View Markdown

Install and Configure

Choose the gateway setup that fits your Qlik environment and security model.

Choose your setup path

Raptor MCP access starts in the web portal. After signup, your account shows the subscriptions, users, add-ons, and gateway options available to your team.

Most customers follow one of three paths: try the sandbox, request hosted gateway access for Qlik Cloud, or prepare an Enterprise Gateway deployment that your own team or partner operates.

  • Request or configure Enterprise Gateway access from Dashboard > Raptor MCP License.
  • Choose the right setup path: sandbox evaluation, hosted gateway access, or customer-hosted Enterprise Gateway.
  • Confirm the Qlik platform, account owner, first users, and buying route before rollout.
  • Validate health and access with a small group before expanding to a wider team.
  • Keep Qlik credentials and gateway tokens in approved secure storage.

Gateway ownership

The gateway is the controlled route between approved AI clients and Qlik. The important decision is who owns that route: Raptor as a hosted service, your team, or an approved partner.

  • Name an internal owner for Qlik approval, user access, and support decisions.
  • Connect only the Qlik environments covered by your license and project scope.
  • Assign migration and specialist services only to the users who need them.
  • Review gateway health before moving from pilot use to broader production use.

Connecting users

Users connect through the gateway from an AI client approved by your organization. Their available workflows depend on the account subscription, user assignment, and Qlik permissions.

For hosted gateway access, each invited user connects their own Qlik account and creates their own token. This avoids shared team credentials and makes access easier to revoke.

  • Qlik Cloud and Qlik Sense delivery support is available through active base subscriptions.
  • QlikView Migration and Power BI Migration are add-on project modules assigned to selected users.
  • Writeback and workflow capabilities are assigned only where users need governed updates, approvals, planning, or operational actions from Qlik.
  • Administrative and analytics support packs are available where licensed.
  • Client setup should follow your security review, identity model, and acceptable-use policy.
  • User tokens are personal secrets and should be replaced if exposed or no longer needed.

InsightOps readiness

If your team plans to use InsightOps, decide who can create notification schedules, which channels are approved for business messages, and which reload or app events should trigger action.

For hosted gateways, admins manage channel and LLM provider settings from the portal. For customer-hosted gateways, those settings stay with the gateway and are managed through the customer-hosted admin interface.

  • Prepare collaboration channels before users create schedules.
  • Confirm whether agent-written summaries are allowed and which LLM provider should be used.
  • Use app and reload event filters so notifications reach the right audience without creating noise.
  • Review delivery evidence and acknowledgement status as part of operational follow-up.

Writeback and workflow readiness

If users will update business records from Qlik, agree the governance model before go-live. Writeback should be treated as an operational capability, not only a visual extension.

Decide which data stores, tables, Qlik apps, roles, reload patterns, approval flows, and notification channels are approved before broader rollout.

  • Use gateway-managed writeback targets so database access is controlled centrally.
  • Map who can submit notes, edit values, save scenarios, approve, reject, or escalate workflow items.
  • Use partial reloads where possible so Qlik can bring back only the new writeback records after a user action.
  • Use audit evidence to track who acted, what changed, when it happened, and which Qlik context was used.

Typical rollout

A sensible rollout starts small: prove the client connection, confirm the Qlik permissions, run a few useful workflows, and then add more users or project modules once the team is comfortable.

  • Start with a sandbox or limited pilot.
  • Move to hosted or customer-hosted gateway access once real Qlik work is in scope.
  • Add partner support when you want help with setup, migration, modernization, or managed analytics delivery.

Before go-live

Before wider rollout, make sure the commercial, security, and Qlik ownership details are clear. This keeps the gateway useful without becoming another unmanaged access path.

  • Confirm whether you are using Qlik Cloud, Qlik Sense Client-Managed, or both.
  • Confirm which users need base access and which need migration or specialist services.
  • Store credentials and tokens only in approved secure locations.
  • Agree who monitors gateway health and who responds when access needs to change.
  • Document partner responsibilities before any partner-managed go-live.

Hosted gateway path

Hosted gateway access is the simplest production path for many Qlik Cloud customers. The dashboard gives admins a place to review setup progress, health, connection details, and user access.

  • Prepare the Qlik Cloud tenant URL and an authorized tenant administrator API key before setup.
  • Confirm the hosted gateway subscription and available gateway capacity before setup begins.
  • Review setup progress, connection details, and health from the dashboard.
  • Invite users only after the Qlik setup and health check are complete.

Previous

Hosted Gateway Access

Next

Enterprise Gateway