NETICE DOCUMENTATION
Source and destination access for Netice
Reviewed
A Netice reporting workflow needs two independent kinds of authorization: access to read the selected Apple or Google reports, and access to write the customer-owned destination. A successful source connection does not prove the destination can be written, and a warehouse login does not authorize platform-report downloads.
For company security information and vulnerability reporting, see Netice’s security policy.
| Boundary | What must be authorized | Typical check |
|---|---|---|
| Apple source | The API key, reporting role and relevant vendor/report scope | Can the selected sales or finance report be retrieved? |
| Google Play source | The source identity and Play Console reporting bucket, including financial visibility | Can the actual Estimated Sales or Earnings object be read? |
| BigQuery destination | Job execution, target dataset writes and staging storage access | Can the workflow stage and load data, beyond merely listing a dataset? |
| Snowflake destination | Key-pair identity, selected role, warehouse, database and schema | Can the role execute work and update the managed output? |
| GCS or S3 destination | Required reads and writes to the selected bucket/path | Can managed history be read and the refreshed output written? |
Keep access scoped to the workflow
Use the setup instructions for the chosen source and destination to grant the operations that workflow needs. Separate reporting access from unrelated administrative access. A dedicated destination dataset, schema or prefix makes that boundary easier to inspect and revoke.
For Google workflows, do not confuse the Play reporting bucket with your destination bucket or BigQuery staging bucket. They can be three different resources with different owners and permissions.
Reuse connections deliberately
Saved connections provide reusable access settings. Before changing one, identify the tasks that rely on it. A connection reused by daily and finance tasks can affect both when its credential is rotated or its scope changes.
- Prepare replacement credentials through the provider’s normal process.
- Update the relevant saved connection in Netice.
- Verify source reads and destination writes using an appropriate reporting scope.
- Retire the previous credential after dependent workflows are confirmed.
Enter source and destination credentials through the connection setup form. Keep credentials out of support messages.
Diagnose the failing boundary
If a report is missing, first establish whether it exists at the source. If it exists but cannot be read, inspect source permissions. If the source read succeeds but no output appears, inspect destination settings and run outcome. If the output is present but the amount surprises you, check report semantics and currency before changing permissions.
Broadening privileges does not fix the wrong report family, an expired Apple report or a dashboard querying the wrong table. Follow the specific Apple access guide, Google access guide and destination guide to isolate the issue.
Access after a handover
Your destination is controlled by your organization. Keep ownership, billing and administrator access with that organization, and manage Netice’s access separately. The portability guide covers how to preserve output and transition downstream reporting.