Privacy & Requester PII

What does the analytics feed expose?

Most fields in the analytics datasets are operational metadata: tenant id, project id, status, timestamps, counts. These don't carry personal data and aren't affected by privacy settings.

The one exception is the requester_email field on the access-requests dataset, which contains email addresses entered by external users when they fill in an access request form. Because Power BI dashboards may be viewed by stakeholders who shouldn't see raw email addresses, Foreman gives tenant admins explicit control over how that field is exposed.

The three columns

The access-requests dataset always returns three related columns:

The hash is deterministic within a tenant — every appearance of alice@example.com resolves to the same 16-char string, so Power BI can group, count, and join on it like any other key. But the hash is different across tenants, so two organisations cannot accidentally correlate users between their dashboards.

When to keep the toggle off (the default)

This is the right setting for almost every customer. Pick this if any of the following apply:

• Your dashboards are seen by people who don't already have access to the underlying access requests in Foreman.
• You operate in the EU/UK and want to minimise the personal data flowing into BI tooling.
• Your security team requires Power BI workspaces to avoid raw PII.
• You intend to publish dashboards externally (e.g. to client stakeholders).

You can still build extremely useful dashboards in this mode:

• Approval rate by domain — "how many requests are coming from acme-engineering.com and what percentage do we approve?"
• Returning vs. new requesters — "how many distinct requesters submitted in Q4?" (using requester_email_hashed as the distinct key)
• Time-to-approval distribution per domain.

When to turn the toggle on

You might want raw emails available if:

• The dashboard is internal-only and audiences are already permitted to see access request details.
• You need the dashboard to deep-link or pivot to other systems keyed on email (CRM, SSO directory).
• A compliance review specifically requires raw email reporting in BI.

How to change the setting

1. Open Power BI Analytics
   Sign in as an org admin and go to Organization → Power BI Analytics.

2. Find the Settings card
   It's the second panel on the page, between Setup and Analytics tokens.

3. Toggle "Expose requester email addresses"

   • Off (default): hides raw emails
   • On: exposes them
     The change takes effect on the next API call — no need to refresh tokens or re-issue.

What about activities and other tables?

Only the access-requests table contains a structured email column. The other tables are unaffected:

• access-request-activities — details_json may rarely contain an email if the activity description references the requester. The toggle does not transform this field.
• qa-check-runs, qa-check-results — no PII, just file metadata and rule outcomes.
• All dimension tables — no PII.

If your compliance posture requires email-free analytics across the board, the safe approach is to drop the details_json column from the access-request-activities table during M-query transformation.

Hash details (for security review)

For tenants that need to document the masking algorithm to their security or compliance team:

• The lowercased email localpart (the part before @) is HMAC-SHA256-hashed.
• The HMAC key is tarmac-analytics|<tenant-id> — different tenants produce different hashes for the same email.
• The hex-encoded output is truncated to 16 characters (64 bits). Collision-resistant enough for tenant-scoped joins.
• Domain is preserved in lowercase. If your threat model rules out exposing domains, drop the requester_domain column in your M query.

See also

• Power BI Analytics Overview
• Issuing & Revoking Analytics Tokens
• Connecting Power BI to Foreman