Issue

Audit log does not capture Atlassian account deactivation event when a managed, non‑IDP‑synced Atlassian account is manually deactivated by an org admin.
Only cascaded product accounts (e.g. Bitbucket) appear in the audit log, with actor shown as "Atlassian Internal System" instead of the actual org admin.

Steps to Reproduce

1. As an organization admin, go to:
   Admin Hub → Directory → Managed accounts.
2. Find a managed Atlassian account that is not synced with an IdP, e.g. abc@atlassian.com
3. Manually deactivate this Atlassian account from the Admin UI.
4. Go to: Admin Hub → Security → Audit log.
5. Filter the audit log with the email ID
6. Look for:
   1. An event describing the Atlassian account deactivation.
   2. Any events related to Bitbucket account deactivation for the same user.

Expected Result

• An audit log entry is recorded for the primary Atlassian account deactivation, for example:
  • Activity: Deactivated account
  • Target: <user-email>@<domain> (the Atlassian account)
  • Actor: the actual org admin who performed the deactivation

• Cascaded product‑level deactivations (e.g. Bitbucket) may also appear, but:
  • They should be clearly linked to the parent Atlassian account event.
  • The actor context should either:
    • Preserve the original admin, or
    • Clearly indicate that it is a system‑initiated cascading action, in addition to the primary admin‑initiated event.

Actual Result

• No audit log entry is recorded for the Atlassian account deactivation itself for a managed, non‑IDP‑synced account.
• Instead, only the cascaded Bitbucket deactivation appears, for example:
  • Activity: Deactivated Bitbucket <abc@atlassian.com> account
  • Actor: Atlassian Internal System
  • Location: Unavailable

• The admin‑initiated action (manual deactivation of the Atlassian account) is not visible in the org audit log:
  • There is no entry that attributes the deactivation to the specific org admin.
  • From the audit log alone, it appears as if the deactivation was performed by an internal system, not by a named administrator.

A similar issue occurs when we deactivate the account from the identity provider the only update we see is Updated account profile for the user and the subsequent group removals alone. There should be another entry stating the user account is deactivated.{}

Impact

• Compliance and auditability:
  Admins and auditors cannot reliably determine which administrator deactivated a user's Atlassian account, which is a problem for security, compliance, and internal investigations.

• Confusing actor attribution:
  The only visible entry shows Atlassian Internal System as actor, which suggests an automated/system event rather than a deliberate admin action.

• Inconsistent behavior:
  • Cascaded product deactivations (e.g. Bitbucket) are logged,
  • But the primary identity event (Atlassian account deactivation) is missing or not visible at the org level for this scenario (managed, non‑IDP‑synced account).