Notifications & Subscriptions

Three separate mechanisms decide whether a given event reaches a given person. They are easy to confuse because all three say “notifications”, so it is worth being precise about which one you are looking at.

Layer	Where	Who edits it	Answers
Notification defaults	Settings > General	Admin	Which channel does each event type use?
Notification subscriptions	Settings > General	Admin	Who gets told about which events?
My subscriptions and preferences	Profile > Notifications	Each person	What do I want, within what the admin allows?

The short version: defaults set the channel, subscriptions set the audience, and personal preferences narrow both, except where an admin has locked them.

Layer 1: Notification defaults

Settings > General. One row per notification type, setting its default channel or channels (in-app, email).

Each row can be locked. A locked row cannot be overridden by an individual, which is how you guarantee delivery of something that matters regardless of what someone has turned off for themselves. Unlocked rows are defaults that people can change under Profile.

Lock deliberately, not defensively

Locking is the only way to guarantee a notification lands, so it is genuinely useful for a small number of types. But it removes the only mechanism people have to manage their own noise, and a tenant that locks everything usually ends up with people who ignore notifications entirely.

Lock the handful that would be negligent to miss. Leave the rest to individuals.

Layer 2: Notification subscriptions (admin)

Settings > General, admin only, requires system:config. This is the tenant-wide routing table: route alerts and scan events to a user or to a team when they match a filter.

A rule has three parts:

1. Who - a specific user, or a team. Team targeting is the reason this exists: work routed to an individual stops when that individual is away, and the events do not.
2. A filter - which events match.
3. Mandatory, optionally - locks the rule so the target cannot opt out of it.

Rules are grouped by target and mandatory ones carry a Locked badge, so you can see at a glance who is receiving what and which of it they cannot turn off.

Applies to: datastores or identities

Each rule targets one subject kind, chosen with the Applies-to switch, and the available axes change with it. A rule only ever matches events about its own subject, so a datastore rule never fires on an identity finding and vice versa.

Datastore rules

Axis	Values
Providers	AWS, Azure
Datastore types	S3 bucket, RDS instance, DynamoDB table, Redshift cluster
Severities	Critical, High, Medium, Low
Alert categories	The alert category set
Regions
Cloud accounts
Datastores	Specific stores

Identity rules

Axis	Values
Identity types	User, Role, Group, Service
Identity flags	Admin access, Over-provisioned, Stale, No MFA, Cross-account, Sensitive data access
Severities	Critical, High, Medium, Low
Alert categories	The alert category set
Cloud accounts

Identity flags match any-of: a rule listing Admin access and Stale fires on an identity carrying either, not only one carrying both.

Leaving every axis empty matches all events of that subject kind. That is a legitimate rule (“tell me about every identity finding”), not a misconfiguration.

What subscriptions currently cover

Rules route scan events, datastore alerts, and identity alerts. What they do not route:

• IAM discovery completed and failed notifications, which still go to everyone holding identity:read rather than following your rules.
• Policy violations, which go to everyone holding policies:read. Note the asymmetry: auto-assignment rules do cover violations, subscription rules do not.
• Compliance control status changes, which emit no notification at all. That is deliberate rather than missing: compliance is a lens on the underlying finding, so the finding notifies and the control does not duplicate it. See Compliance.

Layer 3: Personal preferences

Profile > Notifications, for everyone. One tab holding two things:

My subscriptions - your own additive “notify me” rules. Same filter builder as the admin surface, minus the parts that are not yours to set: no Who picker (the target is always you) and no mandatory lock. Admin mandatory rules that apply to you appear here too, read-only, so you can see what you are receiving and why you cannot turn it off.

Channel preferences - per notification type, which channels you want. Locked rows from the tenant defaults are shown but not editable.

Personal rules are additive. They add events you want; they never remove something an admin has routed to you.

How the layers resolve

For a given event and person, in order:

1. Does a subscription route it to them? An admin rule targeting them or their team, or their own personal rule. Failing any rule, the event falls back to a permission-based audience, for example everyone with alerts:read.
2. Which channel? Their own preference, unless the tenant default for that type is locked, in which case the locked setting wins.
3. Is it a duplicate? Argus de-duplicates so a single event does not arrive repeatedly through several matching rules.

The precedence worth remembering: user preference beats tenant default, except where the tenant default is locked.

Auto-assignment is the sibling, not the same thing

Settings > Security holds Auto-assignment rules, which look almost identical: same filter builder, same user-or-team targeting. They are the same primitive with a different action.

	On a match
Subscription	Sends a notification
Auto-assignment	Sets the owner

One difference in behaviour matters: auto-assignment rules are evaluated in priority order and the first match wins, so a broad rule above a narrow one shadows it. Subscriptions are additive and every matching rule applies.

Assigning an alert also notifies the assignee, so the two interact: an auto-assignment rule is often a better answer than a subscription, because it both tells someone and records that they own it.

A setup that works

1. Set notification defaults for the whole organisation and lock only the few types that would be negligent to miss.
2. Add admin subscriptions for team-level routing, targeting teams rather than individuals for anything with an SLA.
3. Use mandatory only where opting out would be a compliance problem.
4. Let people tune the rest under Profile. If they are drowning, the fix is usually a policy or scope change that stops the events being generated, not more muting. The Noise Ratio on the Alerts Analytics tab is the measure of whether you have got that balance right, and a rising one is the earliest sign people are starting to ignore alerts. See Alerts & Incidents.