Magento extensions

Who changed this Magento price? Start with the price the customer saw.

The admin price still says £89. The customer paid £69. Check the price source before looking for the person who changed it.

Magento admin price change audit trail and user activity log

A customer sends a screenshot: the jacket was £69 yesterday. Its regular price in the admin is £89, and everyone says they left it alone.

Both statements can be true. The customer may have seen a special price, customer-group price or dated catalogue rule. Investigate the price source before treating the question as a missing audit trail.

Follow the effective price

Check the correct website and customer group. Look at advanced pricing, special-price dates and catalogue price rules. Distinguish the product-page price from a discount applied in the cart. Then review integrations, scheduled imports and scripts that can write catalogue values.

Keep the customer's timestamp, website and context. A current value cannot establish the historical offer by itself.

Magento Open Source does not give you the same admin Action Logs feature as Adobe Commerce. If you run Adobe Commerce, assess its native Action Logs report before adding another module.

A useful log answers a specific question

For an admin edit, you want the account, time, record, scope, field, old value and new value. For a sign-in investigation, you want the attempt, result and source. A generic “product saved” entry is often insufficient to settle a pricing dispute.

Our Magento 2 admin log, Admin Activity Log, records supported admin changes with field differences, and keeps sign-in activity separately. Product and rule changes can therefore point to different causes. A catalogue rule edit may explain the lower offer even when no regular-price edit appears.

Admin Activity Log entry with the admin user, IP address and the old and new value of each changed field

Absence from the log is not proof of absence

The module records admin-panel activity and supported CLI configuration changes. It does not capture product changes made through REST or SOAP, cron, command-line imports or direct SQL. An ERP updating a price through an API needs its own integration evidence.

Some queued mass actions show the request and parameters rather than a field-level record for every affected product. Long field values can be truncated. Investigate the job or integration behind the action when you need the full detail.

Most importantly, logging starts when it is installed. It cannot recreate last week's change if no record existed then.

One login per person makes the evidence useful

If several staff members share admin, the log can name only that account. Individual accounts, appropriate permissions and clear ownership improve accountability before you buy any extension.

Keep retention aligned with the incidents you need to investigate. The module's documented default is 90 days. Sensitive fields are masked, but operational logs still need controlled access and an appropriate retention policy.

Use the record to prevent a repeat

After identifying the source, decide what process failed. Was the campaign calendar unclear? Did a website-scope edit affect the wrong shop? Did an import overwrite a manual correction? Logging explains events; it does not replace approval rules or fix integration ownership.

For repeated bulk price changes, pair the audit trail with a preview and undo process. For scheduled price changes, check that cron and indexing are current.

Open the Admin Activity Log demo and inspect a product edit and a rule edit. If your concern is API-driven pricing, tell us that before purchasing. Knowing where the log stops is essential to choosing the right evidence.

From our shop

Related Products

Keep reading

All posts