Unable to Identify Which User Deleted a Person Record in Marketo Engage | Community
Skip to main content
P
Praveenra2
Level 2
February 17, 2026
Solved

Unable to Identify Which User Deleted a Person Record in Marketo Engage

  • February 17, 2026
  • 3 replies
  • 47 views

Hi Community,

We’ve noticed a limitation in #Adobe Marketo Engage regarding person record deletions and would like to confirm if others have experienced the same or if there is a workaround.

Scenario:

When a person record is deleted from the database (either manually or via batch action), we are unable to identify:

  • Which specific user performed the deletion

  • The exact timestamp tied to the user action (beyond high-level activity logs)

  • Any detailed audit reference for compliance tracking

We checked:

  • Audit Trail

  • Activity Log

  • Notifications

However, we could not find clear visibility showing which user deleted the specific contact record.

Concern:

From a governance and compliance perspective, this creates challenges in:

  • Internal accountability

  • Data security monitoring

  • Incident investigation

  • Audit/compliance reporting

Questions:

  1. Is there any hidden audit configuration or advanced log access that tracks user-level deletion details?

  2. Is this information available via API or Admin-level export?

  3. Has anyone implemented a workaround to track user-based deletions?

If this is a product limitation, we believe enhanced deletion audit logging would be a valuable improvement for enterprise environments.

Looking forward to your insights.

Thank you!

Best answer by Darshil_Shah1

Even at the Admin level, there isn’t a clean, user-attributed audit log that shows “User X deleted Person Y at timestamp Z” in a way that’s easily exportable. The API and Support can help in certain cases (as mentioned above), but from a governance perspective, that still leaves a gap.

You can handle this less as a reporting problem and more as a process control issue. A few workarounds include:

 

1. Restrict delete permissions heavily
Limit the “Delete Person” access to a very small number of users (sometimes even a single ops profile). That way, accountability is enforced structurally.

 

2. Avoid direct hard deletes in scattered campaigns
Instead of using “Delete Person” across multiple programs, you should ideally centralize it into one global operational campaign. If another program needs a deletion, it requests that campaign. This creates a controlled funnel and reduces risk.

 

3. Introduce a soft-delete step first
Rather than deleting immediately, you can also first flag the record (e.g., “Deletion Requested = True”) and route it through a review queue. The final delete runs on a scheduled campaign owned by Ops.

 

4. External logging via API
Some users also pull from the Deleted Leads API periodically and store that outside Marketo for independent tracking.

 

So yes, I would consider this more of a product limitation than a hidden configuration issue. If you operate in a compliance-heavy environment, the safest approach is to treat deletion as a privileged, centralized action rather than a broadly available option to all/most users.

 

I hope you find this helpful. Pls let us know if you have any further questions.

3 replies

C
Chargotra
Level 3
February 17, 2026

 

yes this is a probem because Marketo does not natively provide user-level audit visibility for individual person record deletions & for our instance we have Restricted Delete Permissions 

L
leebeasley
Level 2
February 17, 2026

Hi ​@Praveenra2 

 

You can use the GET Deleted Leads API endpoint -- there is a “campaignId” parameter you can reference to see which campaign deleted the lead, if applicable. 

 

If a lead was recently deleted (within the past ~1week or so) Support might be able to restore that deleted lead, and get you some additional details regarding what caused the deletion.

 

Support also has access to a tool that shows which campaigns use the “Delete Person” flow step, so if this is an issue you’re seeing frequently it might be worth asking them to export all campaigns using the delete person action, then audit those to determine if you need them all active.

 

    Darshil_Shah1
    Community Advisor and Adobe Champion
    Darshil_Shah1Community Advisor and Adobe ChampionAccepted solution
    Community Advisor and Adobe Champion
    February 18, 2026

    Even at the Admin level, there isn’t a clean, user-attributed audit log that shows “User X deleted Person Y at timestamp Z” in a way that’s easily exportable. The API and Support can help in certain cases (as mentioned above), but from a governance perspective, that still leaves a gap.

    You can handle this less as a reporting problem and more as a process control issue. A few workarounds include:

     

    1. Restrict delete permissions heavily
    Limit the “Delete Person” access to a very small number of users (sometimes even a single ops profile). That way, accountability is enforced structurally.

     

    2. Avoid direct hard deletes in scattered campaigns
    Instead of using “Delete Person” across multiple programs, you should ideally centralize it into one global operational campaign. If another program needs a deletion, it requests that campaign. This creates a controlled funnel and reduces risk.

     

    3. Introduce a soft-delete step first
    Rather than deleting immediately, you can also first flag the record (e.g., “Deletion Requested = True”) and route it through a review queue. The final delete runs on a scheduled campaign owned by Ops.

     

    4. External logging via API
    Some users also pull from the Deleted Leads API periodically and store that outside Marketo for independent tracking.

     

    So yes, I would consider this more of a product limitation than a hidden configuration issue. If you operate in a compliance-heavy environment, the safest approach is to treat deletion as a privileged, centralized action rather than a broadly available option to all/most users.

     

    I hope you find this helpful. Pls let us know if you have any further questions.

      Terms & ConditionsAccessibility statement

      Loading footer...