Plan repeatable customer analytics setup
Turn a prepared reporting template into a controlled sequence of customer-specific configuration steps.
A repeatable setup process is useful when each new customer needs similar reporting over a different approved dataset or connection. Treat it as a sequence of resource operations with explicit ownership and verification.
Decide what is shared and what varies
Keep the approved dashboard design and KPI definitions separate from customer-specific configuration. Agree which source connection, dataset, audience group, reporting resources and canvas belong to each customer.
Maintain a mapping such as:
| Application record | IFBI references to retain |
|---|---|
| Customer or business-unit key | API root URL (including its configured port, normally 50255) and approved group ID |
| Data configuration | Connection and dataset IDs |
| Reporting workspace | Dashboard, KPI and canvas IDs |
| Deployment record | Template revision, completed steps and verification outcome |
Keep these mappings in your application so you can maintain each customer’s reporting resources. Use the API URL for REST requests; keep the web application URL for the reader’s browser journey. See connection setup for the usual ports and URL format.
Build a staged setup process
- Prepare the data connection. Verify credentials, permitted data and schema compatibility.
- Create or reuse the dataset definition. Map the target account and database type, then validate the saved dataset ID.
- Prepare the reporting resources. Reuse an approved dashboard definition with compatible bindings and configure the required native KPIs.
- Apply the audience configuration. Use existing groups and approved users, or the documented user/group operations where appropriate.
- Create the canvas. Submit explicit dashboard, KPI, group and user ID lists.
- Verify as a reader. Check the actual data, filters, content visibility and expected restrictions with a representative customer identity.
The dataset-reuse and canvas-creation examples in Recipes cover two concrete stages. See dashboard definitions and native KPIs for the related resources.
Make partial progress recoverable
Record each successfully created ID before proceeding. If a later step fails, inspect and reconcile the existing resources before restarting. Avoid a blind retry that creates a second dataset or canvas. Agree a cleanup policy for partially configured resources and retain a record of what your integration created.
Establish the customer boundary explicitly
Configure each customer’s permitted data through the source, connection, dataset and access settings. Group assignments control content access, while dashboard parameters provide reporting inputs. Test that each customer can see their own reporting and cannot reach another customer’s data before rollout.
Next: Users, groups and content access and reliable integration behaviour.
Updated about 8 hours ago