> For the complete documentation index, see [llms.txt](https://docs.nullify.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nullify.ai/configuration/configuration-general.md).

# General Configuration

## Overview

After installation, repository enrollment, and any required onboarding approval, Nullify can assess pull requests and create findings for new risks. The defaults get most teams moving quickly, and you tailor behaviour from the Nullify dashboard (with an equivalent admin API for automation). Configuration no longer lives in a checked-in file — every setting is managed centrally per tenant.

## Where settings live

| Setting                                       | Dashboard                                 | API                                                  |
| --------------------------------------------- | ----------------------------------------- | ---------------------------------------------------- |
| CI / PR gate (fail build, enable PR reviews)  | API; legacy **Configure → Pull Requests** | `PUT /admin/pr-gate-settings`                        |
| Ticket creation thresholds (per finding type) | **Settings → Ticketing**                  | `POST /admin/ticketing/settings/{findingType}`       |
| SLA policies                                  | **Settings → SLA & Effort**               | `POST /admin/sla`                                    |
| Notification destinations + event filters     | **Settings → Connectors**, where offered  | `PUT /admin/integrations/notifications`              |
| Ignore / allowlist a finding                  | Per-finding in the dashboard              | `POST /{service}/.../findings/{findingId}/allowlist` |

### Pull request gate

Control whether the Nullify check can fail CI when a pull request introduces a new finding, the priority threshold that fails it, and whether Nullify may submit an approving review. Use the settings API, or legacy **Configure → Pull Requests** (`PUT /admin/pr-gate-settings`).

`PUT /admin/pr-gate-settings` fields:

* `enabled` — fail the Nullify check when the PR introduces a finding at or above the threshold.
* `minPriority` — the lowest priority that fails the check. Accepts `URGENT` or `IMPORTANT` only.
* `allowApprovingReviews` — allow Nullify to submit an approving review on a pull request that has no blocking findings (off by default).
* `allowRequestChangesReviews` — allow Nullify to submit a request-changes review when it has a blocking security concern (off by default).

See [Pull Request Configuration](/configuration/configuration-pull-requests.md) for the full behaviour of each setting.

### Ticketing thresholds and SLAs

Ticket auto-creation is **off by default** for every finding type until you enable it per type from **Settings → Ticketing** (`POST /admin/ticketing/settings/{findingType}`). Once enabled, a ticket is created when a finding meets both the configured severity and priority thresholds.

Default thresholds once enabled:

* Priority default: **IMPORTANT** (and Nullify never auto-creates tickets below IMPORTANT, regardless of the threshold).
* Severity default: no floor.

SLA policies (time-to-remediate targets per priority) are set with `POST /admin/sla`. Valid priority labels are `URGENT`, `IMPORTANT`, `MEDIUM`, and `LOW`.

### Notifications

Notification destinations and the events that trigger them are managed from connector settings where available, or through the API (`PUT /admin/integrations/notifications`). Nullify supports three destination types, each pairable with an event filter:

* **Slack** — send supported events to configured channels. Microsoft Teams conversations and escalations use their separate integration.
* **Email** — deliver notifications to an address.
* **Outbound webhook** — POST notification events to an HTTPS endpoint you control.

### Allowlisting findings

For finding-level exceptions, use the dashboard or API. Supply-chain policy also supports a coordinate-based package allowlist; see [SCPM settings](/api-reference/api-reference/scpm.md). Suppress a finding per-finding from the dashboard or via the service allowlist endpoint, e.g. `POST /sast/findings/{findingId}/allowlist`. See the per-service configuration pages for the exact paths.

## Autofix pull request limits

Manager campaign planning applies these fixed selection limits:

* **3** open Nullify pull requests per repository at a time.
* **5** new pull requests per remediation plan.

These are campaign-plan limits, not a global throttle on ad hoc dashboard, API, or CLI autofix requests.

Issue dashboards are generated automatically from finding counts; there is no toggle to enable them.

## Document ingestion (Memory Vault)

Nullify can ingest organizational documents from an accessible, enrolled private configuration repository into the Memory Vault. Depending on your platform this repository is:

* GitHub: `.github-private`
* Bitbucket: `.nullify`
* Azure DevOps: `.nullify`

Keep the repository private and grant the Nullify app access. Complete repository enrollment and onboarding; creating the repository alone does not confirm ingestion. Eligible push events upload documents to the vault for organizational context, including security posture, escalation matrices and compliance controls. Verify the imported documents before relying on that context.

Eligible file types:

* Markdown (`.md`)
* PDF (`.pdf`)
* Plain text (`.txt`)
* Structured data: JSON (`.json`), CSV (`.csv`)
* Images: PNG, JPG/JPEG, GIF, SVG, WEBP

Skipped at the repository root (to avoid boilerplate noise): `README.md`, `package.json`, `package-lock.json`, `tsconfig.json`. The same filenames inside subdirectories are ingested normally.

Useful examples to commit: security architecture diagrams, on-call escalation matrices, GDPR/SOC 2 attestations, vendor risk assessments, incident response runbooks, access review exports. Files can also be uploaded interactively from the onboarding UI — both paths feed the same vault.

## Detailed configuration guides

* [Ticket routing, SLAs, and fix effort](/configuration/configuration-ticketing.md)
* [Notifications and delivery controls](/configuration/configuration-notifications.md)
* [Manager autonomy and ground rules](/configuration/configuration-manager.md)
* [Cloud accounts and audit lifecycle](/configuration/configuration-cloud.md)
* [Account access and teams](/configuration/account-and-teams.md)
* [Microsoft Entra SSO, provisioning and recovery](/configuration/account-and-teams/entra-sso-and-scim.md)
* [Azure DevOps installation](/enterprise-tier/azure-install.md)

The current dashboard uses **Settings**; older dashboards use **Configure**. Some controls are API-only. The API field names shown in these guides are JSON names, not database column names.