Know who changed what
See who changed workflows, members, credentials, and more across the organization. WEXTL Activity is the audit trail ops and security ask for.
- GDPR
- Data Encryption
- 2FA
- Local Data Region
Organization activity feed listing recent audit events
What Audit log helps you do
Every org change leaves a row
- 1
A teammate edits, rotates, or removes
Publishing a workflow, rotating a shared credential, revoking an invite, moving a folder — any change to org state is what starts a row, not just workflow edits.
- 2
Actor, verb, and target land as one row
The platform writes a canonical row — actor, verb, target type, timestamp — the same shape whether the change came from a teammate or a WEXTL support actor acting inside your org.
- 3
An org admin filters and jumps to the entity
Narrow by entity type or actor, then open the row's linked workflow, credential, or invite directly to answer 'who changed this and when' without cross-referencing a spreadsheet.
Actor, verb, target — not raw JSON
Every row in the org Activity feed reads as a sentence — "Priya rotated the Stripe credential," "Diego archived the Q3 onboarding workflow" — not a payload you decode by hand.
A workflow that emails customers ships a send step nobody remembers approving. Filter Activity to that workflow's entity and the row shows the exact edit — actor, timestamp, and verb (updated, published, archived) — before you go dig through run history for what actually executed.
Relative time in the row, absolute timestamp on hover — the detail you need when you're lining an edit up against a specific minute in an incident ticket.
When WEXTL support acts inside your org with your permission — restarting a stuck run, fixing a misconfigured webhook — that action lands in the same Activity feed, attributed to the support actor, never merged into a teammate's history.
Reviewing a spike of workflow edits during a security check, an admin can immediately see that 3 of 40 rows are wextl-support, not internal staff, instead of chasing a false alarm.
That separation is what makes the feed usable as evidence in an access review — you can tell the vendor's actions apart from your own team's without a side channel.
Activity rows with actor, verb, and target labels
Narrow to one credential or one workflow
Filter by entity type (workflow, credential, webhook, folder, member) and by actor before you dig — so a busy org's Activity doesn't bury the one change that mattered.
A shared Salesforce credential gets rotated overnight and four workflows start failing at 6am. Filter target=credential, find the rotation event and who ran it, then go straight to the workflow owners instead of pinging the whole team.
Large histories load more with keyset pagination instead of numbered pages, so a year of org activity stays responsive instead of one slow query.
When a teammate leaves, Activity records the membership removal and the invitation revoke — and, separately, any credential rotation or workflow change that happens after — so closing out an access-review checklist means pointing at rows instead of trusting memory.
Was the shared Notion credential this person could see actually rotated after their access was pulled, or only after someone noticed later? The actor/verb/timestamp order on the feed answers that without asking around.
It's the same feed as workflow edits, not a bolted-on IAM log — so the timeline of "who could still touch what" lines up against the timeline of "who changed what."
Activity log filters and feed controls