If your app needs an activity history, define the events it must record: for example, who changed an order's status, when it changed and the previous and new values.
Ask the builder to add a private activity table and write entries from the server operations that perform those changes. Decide who may read the history and whether anyone should be able to edit it. Avoid recording passwords, tokens or unnecessary personal data.
Test the coverage
An activity screen only shows events the app actually records. Test creation, updates and deletion through every supported path. Changes made directly in the editor's Data panel, by a scheduled task or by an integration may take a different path from the page you first tested.
Platform account activity and your app's own business-event history are different records. A login page does not automatically give your app a complete security audit trail.
If the history must be complete or tamper-resistant, specify and verify those requirements separately. A table labelled audit log does not establish either property. Builder changes use credits.