IAM notification settings

IAM Notification Settings

The IAM Notification Settings screen is where you tell DPMS who to contact — and when — if an API token is about to expire. Without these settings in place, tokens can silently run out, breaking any integrations or automated processes that depend on them, with no advance warning reaching your team. IT administrators and Data Protection Officers (DPOs) typically visit this screen as part of IAM hygiene: either when setting up token-based integrations for the first time, or during periodic configuration audits to make sure alerts are reaching the right inbox.

How to open it

Navigate using the left-hand sidebar: IT Settings → expand IAM Settings → click Notifications.

You need the IT Settings IAM permission to access this area. If your account does not have it, you will see a "403 Forbidden" page instead of the notification settings. If the menu item is not visible at all, your role may not include access to the IAM Settings section — contact your system administrator.

What you see

The screen follows the standard IT Settings layout, with the persistent navigation tree on the left and the main content area to the right. At the very top of the content area you will find a breadcrumb trail reading IT Settings → IAM Settings → Notifications, with "Notifications" highlighted in blue to show your current location. Embedded in the breadcrumb are two small arrow buttons (left and right chevrons) that let you step through the IAM Settings sub-sections without going back to the sidebar — useful when you are auditing several IAM screens in one session.

Below the breadcrumb sits a single data card that spans the full width of the page. The card heading says Notifications and beneath it you will see two rows: one for the notification email address and one for the notification days. If nothing has been configured yet, both rows show a dash as a placeholder. In the top-right corner of the card there is an Edit button — that is the only action available on the read-only view of this screen.

Working with this screen

Setting up token expiration alerts for the first time

If your organisation has just started issuing API tokens — for integrations, MCP agent connections, or third-party systems — the first thing to do is configure where the warnings will go.

• On the Notifications screen, you will see both rows showing a dash. Click the Edit button in the top-right corner of the data card. The edit form loads in full-page view, pre-populated with empty values.
• In the Token Expiration Alert Email field, enter the email address that should receive the warnings. This should be an actively monitored inbox — a shared IT mailbox or a distribution list works better than an individual's address, because you want alerts to reach someone even if the usual recipient is out of office.
• In the Token Expiration Notification Days field, type a comma-separated list of numbers. Each number represents how many days before a token's expiry date DPMS should send a warning. For example, entering 60, 30, 14, 7 means the system sends four separate alerts — the first when there are 60 days left, then again at 30 days, 14 days, and 7 days. More thresholds give your team more opportunities to act before a token stops working.
• Before clicking Save, glance at the Maximum Value label displayed just below the notification days field. This shows the upper limit for any single number you enter — for example, if it reads "Maximum value: 90", you cannot set a 120-day warning. The ceiling is set in the general IT settings and cannot be changed from this screen. If you need a higher ceiling, see How this connects to the rest of DPMS below.
• Click Save. DPMS validates your input, saves the settings, and returns you to the read-only view. A brief success notification appears in the top-right corner. Both rows in the data card now show your configured values.

From this point on, whenever any token in your organisation approaches one of the day thresholds you have set, DPMS will automatically send a warning email to the address you specified.

Updating the notification email after a staff change

When the person who owned the notification inbox leaves, or when your organisation restructures its IT mailboxes, you need to update this screen so alerts do not get lost.

• Navigate to IT Settings → IAM Settings → Notifications and review the current email shown in the data card.
• Click Edit. The edit form opens with the existing email address already filled in.
• Clear the Token Expiration Alert Email field and type the new address. Leave the Token Expiration Notification Days field exactly as it is — there is no need to re-enter values you are not changing.
• Click Save. DPMS updates only the email field. The read-only view immediately reflects the new address.

Heads up: There is no confirmation dialog when you click the Back arrow (the left-pointing arrow in the form header) during an edit. Clicking it immediately discards any changes you have made and returns you to the read-only view. If you change your mind mid-edit, use Save rather than navigating away.

Auditing the current notification configuration

Compliance auditors and DPOs often need to check that alerting is active without making any changes.

• Navigate to IT Settings → IAM Settings → Notifications. The read-only view shows the current email address and the notification day thresholds at a glance. No login to any other system is needed — this is your authoritative reference point.
• Note both values for your audit checklist. If either value shows a dash, that is a gap to flag: no alerts are being sent for expiring tokens.
• To move to the next IAM sub-section without using the sidebar, click the right-pointing chevron in the breadcrumb. This steps you directly to the adjacent IAM screen (for example, SCIM or SAML settings) so you can audit multiple IAM configurations in sequence.

Correcting a validation error in the notification days field

The notification days field accepts only positive whole numbers separated by commas. A few common input mistakes will prevent saving.

If you type 30, 14, 7, (trailing comma at the end) and click Save, the form catches the error before sending any request to the server and displays an error toast notification. The form stays open with your values intact. Simply remove the trailing comma and click Save again.

If you enter a number that exceeds the Maximum Value shown beneath the field — for instance, typing 200 when the maximum is 90 — the form also refuses to save and shows an error. Reduce the value to within the allowed range and try again.

Note that if you accidentally enter duplicates (for example 30, 30, 14) or zeros, DPMS quietly removes them and stores only the valid unique values. Always check the read-only view after saving to confirm that the stored days match what you intended.

Field reference

• Token Expiration Alert Email — The single email address that will receive all token expiration warning messages. Enter a valid email address in standard format (for example, it-alerts@yourcompany.com). Only one address can be stored here; if multiple people need to receive alerts, use a shared mailbox or distribution list. The field validates the format on save and will reject anything that is not a properly structured email address. Leaving this field empty means no alerts will ever be sent, regardless of what is entered in the days field.
• Token Expiration Notification Days — A comma-separated list of whole numbers, each representing how many days before a token's expiry date a warning email should be sent. For example: 60, 30, 14, 7. Non-numeric characters (other than commas) are blocked while you type. On save, DPMS removes duplicates, zeros, and any numbers above the Maximum Value shown below the field. A trailing comma at the end of the list will also cause a save error — remove it before clicking Save. Leaving this field empty means no alerts are ever triggered, even if a valid email address is configured.
• Maximum Value (read-only indicator) — Displayed beneath the notification days field. Shows the highest number of days you are permitted to enter in any single threshold. This value comes from the general IT settings and cannot be changed from this screen.

How this connects to the rest of DPMS

The Notification Settings screen is a small but load-bearing part of your IAM configuration. Everything it controls feeds into DPMS's automated token expiration alerting mechanism: when a token's remaining validity falls within one of the day thresholds you have set, the system looks at this screen to find the destination address and sends the warning there. If either field is blank, no warnings are sent — the system does not alert you to that gap; tokens simply expire in silence.

Before you configure this screen, make sure the general IT settings have been completed and that tokenExpirationMaxDaysAllowed is set to a sensible value for your organisation. That value directly constrains what you can enter in the notification days field here. If you find the maximum value is too small for your needs (for instance, you want 90-day warnings but the maximum is 30), you will need to increase it in the general IT settings first.

After you configure this screen, consider verifying the following related IAM screens:

• SCIM settings — to confirm that user provisioning is correctly linked to your identity provider.
• SAML / OAuth settings — to confirm that single sign-on is operational alongside token-based access.
• General IAM settings — to review the overall token lifetime and the maximum days value that governs this screen.

You can reach all adjacent IAM screens quickly using the left and right chevron arrows in the breadcrumb — no need to return to the sidebar each time.

Tips & common pitfalls

Heads up: If both fields are left empty (or if the notification days field is effectively empty after filtering), DPMS will not send any expiration warnings at all. There is no system alert to tell you this — you must check the read-only view after saving to confirm that both values are stored. A dash in either field means alerts are disabled.

Tip: Use a distribution list or shared mailbox rather than an individual's email address. A single-person inbox creates a single point of failure for token expiration alerts. If that person is on leave when a token expires, your integrations may go down without anyone noticing.

• Trailing commas cause save failures. The most common mistake is typing 30, 14, 7, and forgetting to remove the final comma. The form will refuse to save and show an error toast. The fix is simple — remove the trailing comma — but the error message appears as a brief toast at the top of the screen, so if you dismiss it quickly you may wonder why nothing happened. Look for the toast after each failed save attempt.
• The Maximum Value cannot be changed here. The label below the notification days field shows a read-only ceiling. If you need a higher limit — say, 180 days — you must go to the general IT settings section and increase the token expiration maximum there first, then return to this screen.
• Only one email address is supported. There is no multi-recipient option. If your organisation needs alerts sent to several teams, set up a distribution list externally and enter that list address here.
• Duplicate entries and zeros are silently removed. If you enter 30, 30, 14, 0, 7, DPMS saves only [30, 14, 7]. No warning is shown during the save. Always check the read-only view after saving to confirm the stored values are what you intended.
• The Edit button opens a full page, not a modal. Clicking Edit takes you to a new page. The on-screen back arrow (←) in the form header is the safe way to cancel — using the browser's back button can occasionally produce unexpected navigation behaviour within the app's routing.