Group Supervisor Needs Visibility Without Edit Rights
BrightLine has 45 agents across six product groups on a Pro plan. A new Billing team lead needs to see every Billing ticket, reassign work inside Billing, and review CSAT, but must not edit other agents' public replies or delete contacts. Because the team lead could not find a suitable role, an admin made them an Account Admin. Two weeks later, the audit log shows the lead exported 12,400 contacts, changed the account's API key, and added a personal Gmail address as a support email. The security team wants least privilege, but the lead says they need broad visibility to do their job. You must fix access without breaking Billing coverage, and you need to answer whether the API key change requires a broader incident response. The account has SSO available but it is not enforced.
1. What role and group configuration would you recommend, and what would you verify before rolling it back?
Read the worked answer
Remove Account Admin immediately and replace it with the narrowest role that supports the job. On plans with Supervisor, assign Supervisor scoped to the Billing group: that gives visibility across Billing tickets and reporting without account-wide settings. On plans with custom roles, create a 'Billing Team Lead' role with view-all-tickets-in-group, assign/reassign, view reports, and view contacts; disable edit-other-agents-replies, delete contacts, manage account settings, manage API keys, and export contacts. Add the lead to the Billing group only.
Before rolling back, verify with a test account: can see all Billing tickets, cannot see another group's tickets, can reassign inside Billing, cannot change another agent's public reply, cannot export contacts, cannot access Admin. Check that the lead is not inheriting Account Admin through a second role or group. Because Freshdesk API keys inherit the user's permissions, the role change also reduces API risk. Enforce SSO and 2FA at the same time.
2. The API key was changed and contacts were exported. Outline the incident-response steps and the audit evidence you would preserve.
Read the worked answer
Treat the API key change and contact export as a potential data incident until proven otherwise. Preserve audit logs, login history, export records, and the list of integrations and webhooks that used the old key. Do not delete the lead's account or logs. Revoke active sessions, rotate the API key, rotate any webhook secrets, and review recent API calls for unusual endpoints or volumes. Remove the personal Gmail support address and check whether any forwarding rule was created.
Then determine authorization: was the export part of an approved task, and did the lead have permission? If not, escalate to legal/privacy per policy and notify customers only if required after review. Finally, fix the root cause: least-privilege roles, export restrictions for non-admins, SSO enforcement, and a quarterly access review. The API key change alone is serious because it can break integrations silently; the contact export is the bigger privacy risk.