Overview
This skill covers everything required to move a validated Qlik app from development to production (Cloud or client-managed). It does NOT cover data modeling (qlik-data-modeling), script development (qlik-load-script), or security patterns (qlik-security). Why deployment matters: environments differ fundamentally in infrastructure, identity mechanisms, and operational procedures. Qlik Sense Cloud uses OIDC/SAML with email-based identities and cloud storage. Client-managed uses Windows/LDAP authentication and on-premise file servers. This skill bridges those differences with platform-specific procedures.
Section 1: Pre-Deployment Checklist
Verify before deploying any app:
- Execution validation gates passed — Confirm Phase 4 (Scripts) and Phase 5 (Expressions) validation gates completed successfully with developer sign-off, OR documented as "execution validation pending" with tracking
- QA review complete — Phase 7 comprehensive QA completed. All Critical findings resolved. Document any Known Limitations or deferred items.
- Section Access tested — If app uses row-level security, test with at least one non-admin user against target identity provider (Cloud: test OIDC/SAML email user; client-managed: test domain\username user)
- Environment-specific variables identified — List all variables that change between dev/test/prod: connection strings, QVD paths, identity provider URLs, folder locations. Document where each is set (script, data connection, task scheduler)
- QVD storage locations confirmed — Target environment has writable directory/cloud storage paths for QVD output. Verify folder permissions and cloud IAM policies
- Data connections validated — Test each connection in target environment: verify credentials, network access (firewall rules for on-premise sources), cloud data gateway status (if applicable)
- Backup plan documented — Previous app version accessible (QMC app history or storage backup), data snapshot procedure defined, rollback step documented
Section 2: Qlik Sense Cloud Deployment
Space Setup
- Create shared space for collaborative development (all collaborators can edit, monitor task runs)
- Admin > Spaces > New space > Select "Shared space"
- Configure member access (who can edit, who can consume)
- Create managed space for production/governed content (restricted editing, full governance)
- Admin > Spaces > New space > Select "Managed space"
- Assign space owner and data stewards
- Managed spaces support scheduled reload and enterprise security policies
App Import
- Upload via UI (simple for single apps)
- Export .qvf from source environment
- Navigate to target space, click "Upload app" or drag .qvf to upload area
- Qlik extracts embedded data connections and exposes them for reconfiguration
- Import via REST API (automated, preferred for CI/CD)
- POST
/api/v1/apps with .qvf file upload
- Specify
spaceId in request body
- Response includes
appId for downstream reference
Data Connection Setup
- Cloud-native connections (data in Azure, AWS, Google Cloud)
- Admin > Data connections > New connection
- Select cloud provider (Azure Data Lake, Amazon S3, Google BigQuery)
- Configure credentials (SAS token, IAM role, API key)
- Test connection before using in app
- On-premise data access (databases, file shares in corporate network)
- Deploy Cloud data gateway in target network (download from help.qlik.com)
- Register gateway with Qlik Cloud tenant
- Create data connection in Qlik Cloud pointing to gateway
- Verify network connectivity: gateway must reach source system and reach Qlik Cloud
- Common gotcha: firewall rules blocking gateway ↔ data source or gateway ↔ Qlik Cloud traffic
- Generic REST connector
- Use for SaaS APIs, webhooks, custom endpoints
- Test endpoint accessibility from Qlik Cloud infrastructure
Reload Scheduling
- Create reload task (built-in Cloud task scheduler)
- Navigate to app > Reload task
- Set trigger: immediate, scheduled (cron pattern), or webhook
- Configure failure notification (email to operations team, webhook to monitoring system)
- Test first reload manually to verify no errors
- Common pattern: reload nightly, alert on failure
- Monitor reload health
- App > Activity > Reloads
- Check last reload status, duration, error logs
- Set up monitoring alert if reload fails or exceeds threshold duration
Security Configuration
- Configure identity provider (done once at tenant level, applies to all apps)
- Admin > Identity providers > Configure OIDC or SAML
- Map external identity provider (Okta, Azure AD, etc.) to Qlik Cloud
- Users authenticate via single sign-on (SSO)
- Verify email attribute maps correctly (used in Section Access USER column)
- Section Access identity mapping
- In script, use email address in USER column:
USER, DepartmentID from [UserSecurityTable.qvf] where USER contains [email protected]
- Qlik Cloud matches logged-in user email to Section Access USER entries
- Verify with test user: log in, check what data is visible (should match assigned department)
- Space-level access control
- Additional layer: even if Section Access grants access to data, user must have space permission to see app
- Assign space members individually or via LDAP group sync
Content Distribution
- Publish app to make discoverable
- App > Publish (makes app appear in app library for assigned users)
- Share link with users (email, intranet, analytics portal)
- Master items (reusable dimensions, measures, filters)
- Create once in Qlik Cloud app
- Reference in multiple sheets (changes apply automatically)
Section 3: Qlik Sense Client-Managed Deployment
Stream and Security Rule Setup (QMC)
- Create stream (container for apps, enforces access policy)
- QMC > Streams > New stream
- Stream = logical grouping (Production, Staging) or business area (Sales, Finance)
- Note stream GUID for app assignment
- Create security rule (QMC > Security rules)
- Define who can access which streams
- Example:
resource.stream.id = "xxx" and user.name = "DOMAIN\*"
- Apply rule to apps in stream
App Import
- Via QMC
- QMC > Apps > Import app
- Upload .qvf from development
- Select target stream
- Specify publishing on/off (make immediately available to users)
- Via REST API (automated)
- POST
/qrs/app/upload with .qvf content
- Include stream ID in request
- Response includes app GUID
Data Connection Setup (QMC)
- Folder connection (for QVD access, file shares)
- QMC > Data connections > New
- Type: Folder connection
- Path: UNC path (
\\server\share\qvd) or local path
- Credentials: Windows account (NTLM) or custom credentials
- Test: "Test connection" button verifies folder accessibility
- Database connection (SQL Server, Oracle, Teradata)
- QMC > Data connections > New
- Type: database-specific (ODBC, native driver)
- Credentials: database user + password, or Windows auth (single sign-on)
- Connection string example:
DRIVER={SQL Server};SERVER=dbhost;DATABASE=mydb;
- Test connection before using in app
- Custom connector (API, specialized sources)
- Configure in QMC if vendor provides connector
- Or use generic REST connector with API credentials
Task Scheduling (QMC)
- Create task (reload automation)
- QMC > Tasks > New task
- Type: Reload (app refresh) or external program
- Select app to reload
- Set trigger: immediate, scheduled (cron), or on-success-of-another-task
- Example: App-A loads at 6am, App-B triggers on App-A success at 6:30am
- Task chain (dependency management)
- Task A: Reload core data app (6:00 AM)
- Task B: Reload reporting app (trigger: on success of Task A, 6:30 AM)
- Task C: Send completion email (trigger: on success of Task B)
- Prevents cascading failures (Task B doesn't run if Task A fails)
- Failure handling
- Configure alert (email, webhook) if task fails
- Set retry policy (retry N times before alert)
- Manually retry task from QMC if needed
Security Configuration
- Identity provider setup (QMC > Identity providers)
- Windows (NTLM/Kerberos) — Automatic for domain-joined servers
- LDAP — Configure LDAP server address, bind credentials, user attribute mapping
- SAML — Configure identity provider metadata
- Result: Users authenticate once; Qlik Sense recognizes user identity
- Section Access identity mapping
- Use NTNAME field for domain\username:
NTNAME, DepartmentID from [SecurityTable.qvf] where NTNAME = DOMAIN\AliceSmith
- Or use USERID field for internal numeric ID (less common)
- Qlik Sense matches logged-in user identity to Section Access entries
- Test with sample domain user
- Custom security rules
- Fine-grained access beyond Section Access
- QMC > Security rules > New rule
- Rule pattern:
resource.app.name = "Production*" and user.group = "DOMAIN\Analysts"
Multi-Node Architecture (if applicable)
- Central node (master) — Hosts QMC, task scheduler, shared license. Only node that can write to file system.
- Rim nodes (workers) — Reload engines only (no QMC). Configured in QMC to share reload load.
- Engine distribution — Configure via QMC which engines handle reload tasks. Reduces central node bottleneck.
Section 4: Environment Promotion (dev → test → prod)
What Changes Between Environments
| Aspect | Dev | Prod |
|---|
| DB Connection | SERVER=db-dev.corp.com | SERVER=db-prod.corp.com |
| QVD Path | \\fileserver-dev\qvd\ | \\fileserver-prod\qvd\ |
| Section Access Source | Test user list | Production LDAP or IdP |
| Data Connection Credentials | Dev service account | Prod service account |
| Task Schedule | On-demand | Hourly |
| Monitoring | Warnings only | Alerts + escalation |
Do NOT hardcode these values in scripts. Externalize to variables.
Variable Externalization Strategy
- Create environment variables file (.qvs for each environment):
// Environment variables (included in main script)
LET vDbHost = 'db-prod.corp.com';
LET vDbPort = '1433';
LET vQvdPath = '\\fileserver-prod\qvd\';
LET vSecAccessSource = 'SecurityTable_Prod';
LET vReloadTime = '23:00';
Promotion Workflow
- Export from dev — Publish app as .qvf (includes all objects, data model, scripts)
- Import to test — Upload .qvf to test environment, reconfigure data connections (point to test database)
- Validate in test — Full test suite: reload, row count verification, Section Access testing with test users
- Promote to prod — Export from test (or dev), import to prod
- Post-prod validation — First reload, data freshness check, test with subset of production users
Configuration Management
- Version control (Git) — Store main script files, variable definitions, naming conventions
- Do NOT version control: environment-specific connection strings, credentials, QMC task IDs
- Deployment checklist — Document what changed between environments (connection strings? Section Access source? Task schedule?)
- Rollback plan — Keep previous app version accessible (QMC app history or backup)
Section 5: QVD Storage Setup
Folder Structure
/qvd/
/raw/ # Source data extracts (unchanged from source)
/sales.qvd
/customers.qvd
/transform/ # Intermediate tables (after business logic)
/sales_enhanced.qvd
/customer_segments.qvd
/model/ # Final dimensions and facts (ready for consumption)
/dim_customer.qvd
/fact_sales.qvd
/fact_inventory.qvd
/archive/ # Historical QVDs (retain for recovery, backup)
Permissions and Access Control
- Read access (for load scripts) — All users/service accounts running Qlik reload
- Write access (for QVD output) — Only Qlik reload engine service account
- Archive access — Backup/IT team only (for disaster recovery)
- Cloud-specific — Use cloud storage permissions (Azure blob ACL, S3 IAM policy)
Retention and Cleanup
- Keep latest QVD always (allows rollback to previous load)
- Archive previous 7 days (recover from logic errors discovered mid-week)
- Monthly snapshots (audit trail, historical analysis)
- Automated cleanup — Delete files older than 30 days via OS task scheduler or cloud lifecycle policies
Section 6: Post-Deployment Validation
First Reload Verification
- Manual reload — Run reload task, watch for errors
- Check reload log: no ERROR or FATAL messages
- Check TRACE output (if qvf includes TRACE statements) for data quality warnings
- Row count verification — Compare row counts in target vs. source (should match within expected margin)
- Field type consistency — Verify numerics loaded as numbers (not text), dates as dates
Data Freshness and Accuracy
- Spot-check totals — Select 2-3 key metrics, verify against source system (example: "Total revenue should be $X million")
- Synthetic key check (client-managed) — Data model viewer should show NO red-highlighted synthetic keys
- NULL handling — Verify expected NULLs appear (no spurious NULLs hiding bugs)
Security Validation
- Test with restricted user — Log in as non-admin user, verify data reduction works (user assigned to Department A should NOT see Department B data)
- Test with admin user — Verify admins see complete data (no unintended filtering)
Performance Baseline
- Reload duration — Record baseline (15 min? 2 hours?). Alert if reload duration increases >20%
- Memory usage — Check peak memory during reload. Allocate Qlik engine accordingly.
- Disk space — Monitor QVD storage growth. Implement cleanup policy if growth exceeds threshold.
Monitoring Setup
- Reload alerts — Configure alert (email, Slack, monitoring tool) if reload fails or duration exceeds threshold
- Data freshness — Daily check that reload ran successfully and data is current
- User access logs — Monitor failed logins (indicator of Section Access misconfiguration)
- Dashboard notifications — Notify users of any scheduled downtime or data refresh delays