devguard

Account

Manage your profile, sign-in security, notification preferences, organizations and API tokens.

Overview

The Account area holds everything that belongs to you rather than to an organization: your profile and sign-in details, how devguard notifies you, the organizations you are a member of, and the API tokens you created. What you change here follows you into every organization you belong to.

The organization's own settings (name, integrations, billing) live under Settings. The two areas link to each other from the right end of their tab bars. People and business roles are managed under People.

Profile

Update your Avatar, Name and Email. You can also choose your preferred theme (light/dark) and language.

Expert Mode

Enable Expert Mode to display additional object information such as UUID, creation date, and last updated date. This is useful for debugging, data exports, and imports.

Deleting an Account

Account deletion is irreversible. You must transfer or delete ownership of all organizations before deleting your account.

Security

How you sign in, and what protects it.

  • Sign-in methods: you always sign in with a code emailed to your address. Signing in with Google, Microsoft or Apple once links that account, and it is listed here. Accounts created before codes keep their password, which you can still change here.
  • Two-factor authentication: after the emailed code or a passkey, devguard also asks for a code from your authenticator app. Sign-ins through Google, Microsoft or Apple rely on that provider's own security instead. Your organization may require two-factor authentication.
  • Trusted devices: when you tick Trust this device at sign-in, that browser skips the authenticator code for 30 days. Forget trusted devices makes every device ask again. Your organization can turn trusted devices off; then every sign-in asks for the code.
  • Passkeys: sign in with Face ID, Touch ID or Windows Hello instead of an emailed code. Add one from here, or accept the offer after you sign in.

Turning two-factor authentication on or off, and adding or removing a passkey, asks you to confirm it is you when your last sign-in is more than a few minutes old.

Notifications

Control what devguard tells you about, and how. Preferences live on one screen and apply to your account across every organization you belong to.

Every notification is a category delivered over one or two channels: in-app, email, or both. The two channels are independent, so you can keep something loud in-app and silent by email, or the reverse. Turning one off never affects the other.

In-app

In-app notifications appear in the bell in the top bar. It shows an unread count, and opening it reveals your inbox, a list of recent items split into Unread and All. Selecting an item marks it read and takes you straight to what it is about: the policy, the review, or the deadline. The same feed is surfaced on your dashboard, so you can triage without leaving what you are doing.

This is the quiet, always-there channel. Nothing lands in your mailbox; the unread count simply updates the next time the app loads. In-app is on by default for every category that supports it, because the inbox is where you look to see what has happened without being interrupted.

Email

Email notifications are sent to your account email address. This is the channel that reaches you when you are not in devguard, which matters for time-sensitive things like an overdue review. Email starts off for every category except System, so turn on the ones you want. Portal employees, who have no in-app inbox, set theirs under Email notifications on their portal Profile. For most categories you choose the cadence:

  • Instant: one email per event, sent as it happens. Best for things you may need to act on the same day. It is the default.
  • Weekly digest: events are held back and arrive together in one email at 07:00 UTC on the day you pick. The hour is fixed rather than local, so far enough west it can reach you late on the previous evening. Choosing weekly reveals a day selector next to the cadence; the digest goes out that morning, grouped into a section per category, so a week of policy approvals and due dates is one email rather than a dozen. Nothing is dropped along the way: an event queued after the send time simply waits for the following week. Keep a category on instant if you need same-day notice.

One thing to know about the weekly cadence: an event's place in a digest is fixed when the event happens, not when the email goes out. A change you make here therefore applies to what happens after it. A digest that is already scheduled still arrives on its original day, carrying the items it had collected by then, so turning a category off, moving it back to instant, or picking a different day all take effect from the next event onward rather than emptying the digest already in flight.

Marketing email is email-only by nature and has no in-app equivalent. System emails, such as password resets and email changes, always send regardless of your other settings.

How the two work together

In-appEmail
WhereThe bell and inbox in the app, plus the dashboardYour account email address
Best forTriaging while you workReaching you when you are away
TimingUpdates when the app loadsInstant, or once a week on the day you pick
DefaultOnOff until you turn it on (System is always on)

Because the channels are separate, a common setup is in-app for everything, email only for the categories you must not miss (for example, deadlines). Set this per category on the Notifications tab: toggle in-app and email independently, and where a cadence selector is offered, choose instant for what you must act on the same day and weekly for the rest.

Categories

  • Deadlines: reviews, assessments, remediation and assignments that are due or overdue. You are notified at set lead times (ahead of the date, a day out, and once overdue) and never twice for the same point, so a busy period does not bury you in repeats. The first lead is a week for most items; for policy and training assignments it follows the cadence instead, stretching to a month ahead of a yearly one.
  • Assignments & mentions: when you are made responsible for something, or an object you own is referenced elsewhere.
  • Policies: approvals and new versions of policies you own or approve.
  • Updates to your items: when someone changes the status or key details of an item you own or oversee.
  • Marketing: optional product updates and surveys.
  • System: account notifications such as email changes and password resets. Always on and cannot be disabled.

Defaults

In-app notifications are on by default, so your inbox is never empty of things you are entitled to see. Email is off until you turn a category on, except System, which always sends. A category you turn on starts at instant, so nothing waits a week unless you ask it to.

Organizations

Every organization you belong to, with your role in each. The tab only appears once you are a member of more than one organization, because the one thing it offers is a way out.

Leave removes you from an organization you no longer work with. You lose access to everything in it; your business role assignments and everything you created stay with the organization, attributed to you in its audit log. Leaving the organization you are currently working in switches you to another of yours and reloads the app there.

An owner cannot leave. Transfer ownership under the organization’s Settings first, then leave as an admin or member. You also cannot leave your only organization: there would be nothing left to sign in to, and deleting your account is the honest version of that wish.

Administrators cannot remove themselves from the People list either; this page is where that happens.

Tokens

API tokens let a script or tool authenticate against the devguard API without a browser session. They live under Tokens, which documents creating and revoking them, what a token is allowed to do, the rate limits and the response codes in one place.

Whatever you build with one, the rules are the same: store it as a masked secret, never commit it, use the shortest expiry the job tolerates, and delete it the moment it is exposed or unused.

How is this guide?

On this page