Vigilfield Docs
Organization and access

Activity

See who changed a resource, and when, on its own page.

Every detail page in Vigilfield ends with an Activity section: the recent changes to that resource, newest first. It is on the pages for alerts, rules, queries, tables, sources, investigations, folders, alert destinations, apps, installations, users and teams.

Activity is read from the audit log. It shows the last 20 changes from the last 90 days. A new change can take a few minutes to appear.

Who sees it

Anyone who can open the resource's page sees its Activity. The section follows the page's own access: if you cannot open the page, you cannot read its Activity.

People read Activity; apps cannot. A request made with an app's credentials is refused.

What it shows

Each row has the time, who acted and what they did.

  • Who is a person, by name (their user id when they have no name), an app installation, by its app's name (its installation id when the app is not shown to you), or Identity provider for changes your SSO provider made through SCIM. Email addresses are never shown.
  • What is the change, such as "Muted the rule" or "Added a team member". A change that names another resource, such as adding a member to a team, shows on both pages and reads the same on each.
  • Changes that were refused are marked Refused. Changes that failed are marked Failed.
  • Owners and admins also see the IP address each change came from.

Activity covers changes made through the app and the API. It does not show:

  • views and reads, such as opening a page or reading a query's results;
  • changes Vigilfield makes on its own, such as a rule's scheduled runs;
  • grants, exports and organization exports;
  • sign-ins and your own account settings, such as your password or MFA;
  • the resources a team transfer moves (the team's page shows the transfer);
  • anything from before Activity was added.

The full history

Activity shows 20 changes. The audit log keeps everything. Owners and admins see Open in query under the section. It opens the query editor with a query that selects every audit event about this resource, with no 90-day limit.

vf_audit_events is a system table, so running that query needs Run as admin (audited) and a reason. See System tables and the admin override.

For a rule with the id rule-1a2b3c4d5e6f7a8b, the query is:

vf_audit_events
| where ocsf.vigilfield.subjects matches regex '(^| )rule:rule-1a2b3c4d5e6f7a8b( |$)'
| sort by vf_event_timestamp desc

The audit log has three fields for this:

FieldWhat it holds
ocsf.vigilfield.subjectsThe resources an event is about, separated by spaces, each as <kind>:<id>, such as rule:rule-1a2b3c4d5e6f7a8b or team:team-0f1e2d3c4b5a6978. Empty for reads.
ocsf.vigilfield.outcomeHow the call ended: ok, rejected or error.
ocsf.src_endpoint.ipThe IP address the call came from.

The kinds are alert, rule, query, table, source, investigation, folder, alert_destination, app, installation, user and team.

Over the API

Each kind has a route: GET /<kind>/{id}/activity, such as GET /rules/{id}/activity. The answer's data holds the rows, newest first. Owners and admins also get each row's ip and an audit_query, the query above.