Administration

The administration section allows managing users, roles, permissions, SMTP settings, alarms, webhooks, audit logging, and licensing.

Access it through the gear icon (⚙️) in the side menu → Settings.

Users

Inviting Users

1. Go to Settings → Users
2. Click Invite User
3. Fill in:
   • Email: New user's email address
   • Role: Assigned role (defines permissions)
4. An invitation email will be sent with an activation link

Requirement: SMTP must be configured for sending invitations.

Bulk Import

To register multiple users at once:

1. Go to Settings → Users
2. Click the import icon (next to the invite button)
3. Download the Excel template by clicking Download Template
4. Fill in the spreadsheet with user data:

5. Upload the Excel file (.xlsx or .xls) by dragging it to the designated area or clicking to select
6. The system will process each row and send invitation emails

After processing, a summary is displayed showing:

• Number of users successfully imported
• List of failures with the row number, email, and reason for the error (e.g.: email already exists, role not found, missing required fields)

Note: The import respects the license's user limit. If the file contains more users than the plan allows, the system will notify you and offer the option to import only up to the available limit.

Managing Users

In the user list you can:

User Status

Roles and Permissions

System Roles

QANode includes predefined roles that cannot be removed:

Custom Roles

Create roles with specific permissions:

1. Go to Settings → Roles and Permissions
2. Click + New Role
3. Define the name, table view, and select the permissions

Table View

When creating or editing a role, the Table View field defines which database tables are accessible in the query builder of custom dashboards. This controls what the user can query when creating widgets with SQL queries or exploring data in dashboards.

Note: Sensitive columns (passwords, tokens, encrypted data) are automatically hidden, regardless of the view profile.

Default profiles for system roles

Complete Permissions List

Scenarios (Flows)

Projects

Suites

Executions (Runs)

Variables

Credentials

Providers

Reports

Dashboards

Webhooks

Users

Roles

Bugs — Enterprise

Settings

SMTP Configuration

For sending emails (invitations, reports, alarms):

1. Go to Settings → SMTP
2. Fill in:

3. Click Save — the system tests the connection automatically

Integration Tokens

Integration Tokens allow pipelines and automations to authenticate without relying on a browser session.

To access them:

1. Go to Settings → Access Tokens
2. Generate a token
3. Store the value as a pipeline secret
4. Use it with QANODE_URL and QANODE_TOKEN

Users with settings.integration_token_all can also:

• view tokens from the whole instance
• revoke tokens created by other people
• define the global expiration policy

For the complete guide, see CI/CD Integration — Overview.

Alarms

Configure automatic notifications for suite failures:

1. Go to Settings → Alarms
2. Configure:
   • Monitored suites — which suites trigger an alarm
   • Recipients — who receives the notification
   • Condition — when to notify (failure, always, etc.)

Requirement: SMTP must be configured for sending alarms by email.

Webhooks

Webhooks allow automatically sending HTTP POST notifications to external services when execution events occur. Each user manages their own webhooks independently.

Configuring Webhooks

1. Go to Settings → Webhooks
2. Click + New Webhook
3. Fill in:

Available Events

Test execution

Defects

Scope (Filters)

You can filter webhooks to trigger only in specific contexts:

• Project — Only events from a specific project
• Suite — Only executions from a specific suite (test execution events only)
• Scenario — Only events from a specific scenario/flow

When selecting a project, suites and scenarios are filtered to show only those belonging to that project. When selecting a suite, the scenario filter is hidden.

Note: Suite scope does not apply to defect events. A webhook scoped to a suite will only fire for test execution events (run.*, suite.*), never for defect events.

Webhook Payload

Every delivery is an HTTP POST with the following JSON body:

{
  "event": "<event-name>",
  "timestamp": "2026-04-15T10:30:00.000Z",
  "data": { ... }
}

Test execution payload

{
  "event": "run.completed",
  "timestamp": "2026-04-15T10:30:00.000Z",
  "data": {
    "runId": "uuid",
    "flowId": "uuid",
    "flowName": "Login Flow",
    "suiteId": "uuid",
    "suiteName": "Smoke Suite",
    "projectId": "uuid",
    "projectName": "App Mobile",
    "status": "success",
    "durationMs": 1234,
    "executor": "Username",
    "errorSummary": null
  }
}

Defect payload (defect.opened, defect.status_changed, defect.closed)

{
  "event": "defect.status_changed",
  "timestamp": "2026-04-15T15:10:00.000Z",
  "data": {
    "defectId": "uuid",
    "defectNumber": 42,
    "title": "Login button does not respond on Safari",
    "description": "When clicking Login on Safari 17...",
    "status": "in_progress",
    "previousStatus": "open",
    "severity": "high",
    "priority": "urgent",
    "resolution": null,
    "isFinal": false,
    "closedAt": null,
    "createdAt": "2026-04-15T14:32:00.000Z",
    "updatedAt": "2026-04-15T15:10:00.000Z",
    "project": { "id": "uuid", "name": "App Mobile" },
    "flow": { "id": "uuid", "name": "Login Flow" },
    "run": { "id": "uuid", "status": "failed" },
    "reporterUser": { "id": "uuid", "name": "Maria", "email": "maria@company.com" },
    "assigneeUser": { "id": "uuid", "name": "João Silva", "email": "joao@company.com" },
    "assigneeRole": null,
    "customFields": { "environment": "production", "browser": "Safari 17" },
    "actionComment": {
      "content": "Starting investigation on staging",
      "user": { "id": "uuid", "name": "João Silva", "email": "joao@company.com" }
    }
  }
}

HMAC Signature

If the Secret field is filled in, QANode adds the X-QANode-Signature header with the HMAC-SHA256 signature of the payload. This allows the receiving service to validate the authenticity of the request.

Example header:

X-QANode-Signature: sha256=abc123...

Retries

In case of delivery failure (network error or HTTP code other than 2xx), QANode automatically retries up to 3 times with increasing intervals:

Delivery Log

For each webhook, you can view the history of the last 50 deliveries:

1. Click the list icon next to the webhook
2. View the status of each delivery (OK/Failed), HTTP code, attempts, and errors

Testing Webhooks

Click the play icon next to the webhook to send a test payload. This allows you to verify that the URL is accessible and responding correctly.

Permissions

The following roles have access to webhooks:

Each user views and manages only their own webhooks.

Audit

The audit log records all important actions in the system:

Tracked Actions

Tracked Entities

Projects, Flows, Suites, Runs, Variables, Credentials, Providers, Users, Roles, Settings, System.

Log Information

Viewing

1. Go to Settings → Audit
2. Navigate through the history using pagination
3. Use filters to search for specific actions

Password Change

Any user can change their own password:

1. Go to Settings → Change Password
2. Enter the current password
3. Enter and confirm the new password
4. Click Save

MFA (Two-Factor Authentication)

For greater security, enable two-factor authentication:

1. Go to Settings → MFA
2. Scan the QR Code with an authenticator app (Google Authenticator, Authy, etc.)
3. Enter the generated code to confirm
4. MFA will be active — codes will be requested at each login

License

Manage the QANode license:

1. Go to Settings → License
2. View:
   • License Status (valid/expired)
   • Expiration date
   • Remaining days
   • User limit
   • Active users vs limit

Tips

• Configure SMTP first — many features depend on email
• Use custom roles for fine-grained access control
• Monitor the audit log regularly to detect unexpected actions
• Enable MFA for administrator accounts
• Deactivate users instead of deleting — preserves audit history
• Use webhooks to integrate QANode with Slack, Teams, Discord, or any service that accepts HTTP POST
• Set the secret on webhooks to ensure request authenticity