Data destinations

Connects KPImailer to external SQL databases that reports can export live Qlik data into, alongside or instead of emailing it.

Permissions

Found in Settings → Data destinations, an administrator-only area. Once a destination exists here, report authors can target it from SQL data exports when building a report.

Steps

1. Open Settings → Data destinations and select Add destination.

   

2. Give it a Name and choose the Engine: SQL Server, PostgreSQL, MySQL, or Oracle.

3. Fill in Database, Host, and Port (leave Port blank for the engine’s default).

4. Set Username and Password - leave Username blank for integrated authentication where supported. Passwords are encrypted and never shown again.

5. Optionally set a Schema (defaults to the engine’s default) and Advanced options as key=value;key=value pairs for connection-string extras your database needs.

6. Add a Description to help report authors pick the right destination.

7. Leave Require TLS on unless your database doesn’t support encrypted connections. Only enable Trust server certificate for trusted internal servers where you’re skipping certificate validation deliberately.

8. Select Save destination.

When to change this

• Standing up a new data warehouse or reporting database - add it here once, then any report author can export into it.
• Database credentials rotate - edit the destination and update Username / Password; existing reports keep working without changes since they reference the destination by name.
• A destination is retired - remove it here, and update any reports that exported to it.

Worked example

A finance team wants commission data landed in their own SQL Server warehouse instead of just emailed. An administrator adds a destination named “Finance warehouse” with the warehouse’s host, port, and a dedicated read/write account, leaves Require TLS on, and saves. The commission report’s author then picks “Finance warehouse” under SQL data exports so every run lands a copy in the warehouse automatically.

What can go wrong

Caution

Turning off Require TLS sends credentials and data unencrypted over the network - only do this for a database you control on a trusted internal network, never over the public internet.

Caution

A destination with the wrong Schema or insufficient database permissions fails silently from the report author’s point of view until the report actually runs and the export step errors - test with a low-stakes report before pointing a production schedule at a new destination.