Advanced Settings

Reference of advanced settings for Ketryx organizations and projects

Ketryx is highly configurable using advanced settings at the organization and project level.

To access or change the organization-level settings (under Organization > Advanced), you need to be an organization owner. You can also change project-level default settings at the organization level; projects will inherit these defaults for each setting, unless the setting is explicitly defined at the project level.

To change the project-level settings (under a project's Settings > Advanced), you need to have the Manage project permission.

Keep in mind that configuring these advanced settings incorrectly can have undesired consequences for your configuration items, Jira configuration, and member authentication. Proceed with care. When in doubt, please contact Ketryx Support. By design, not all internal settings are exposed. Also note that some parameters might change in future releases.

Advanced settings are generally specified as JSON values. Watch out for proper delimiters, punctuation, and nesting when editing these values.

Some settings involve internal IDs (e.g., for item types, document types, or field keys). These IDs are documented in the Internal IDs section at the end of this reference.

Global item configuration

Item type names

Mapping of standard item type names (e.g. "Requirement") to user-defined custom names (e.g. "Feature").

This is commonly used in combination with custom settings for Item type short names and Superseded item types.

Warning: If connected to Jira (and not in read-only mode), Ketryx will change some settings (e.g. icons) of issue types matching the names of the configured item types. This will result in a global configuration change in a connected Jira instance.

Use the item type name "Feature" instead of "Requirement"

{
  "Requirement": "Feature"
}

Item type short names

Mapping of standard item type names (e.g. "Requirement") to user-defined custom short names (e.g. "FEAT").

Note that the standard type name (e.g. "Requirement") is used even if the type has been renamed (e.g. to "Feature") via the Item type names setting.

Note: The given short names must be unique.

Use the short names "FEAT" for Requirements

{
  "Requirement": "FEAT"
}

Superseded item types

For each (custom) issue type name, a list of issue types it supersedes (if any). When a superseded issue type exists, it will be renamed to the new name (e.g. "Requirement" -> "Feature"), rather than creating a new issue type.

This is only effective in combination with a setting for Item type names. It only affects the Jira configuration process in case the new issue type does not exist yet. If both the previous and the new issue type exist already, the previous issue type will not be removed or renamed.

Warning: This will result in a global configuration change in a connected Jira instance.

Rename the "Requirement" issue type to "Feature"

{
  "Feature": [
    "Requirement"
  ]
}

Field names

Custom name of each field, as a mapping from system field keys to custom names.

This can be used in combination with Superseded field names when switching from one custom name to another custom name.

Warning: Fields with custom names are created (or updated) as custom fields in Jira, rather than using the fields provided by the Ketryx Jira app. Previous field values might have to be migrated from the previous field to the new field in Jira (Ketryx will not perform this Jira data migration automatically).

Note that, by default, Ketryx will not change the available option values for such custom fields, neither the default values nor custom values defined via Select field options. When editing such items in Ketryx, synchronizing changes to Jira might fail if the used values are not configured manually in Jira.

Rename "Regions" to "Regulatory regions"

{
  "regions": "Regulatory regions"
}

Field descriptions

Custom description of each field, as a mapping from system field keys to custom descriptions.

Add description to the "Regulatory regions" field

{
  "regions": "The regulatory regions in which the item is applicable."
}

Superseded field names

For each field key with a custom name, a list of field names that it supersedes (if any). When a superseded (custom) field exists, it will be renamed to the new name, rather than creating a new field.

This is only effective in combination with a setting for Field names. It only affects the Jira configuration process in case the new field does not exist yet. If both the previous and the new field exist already, the previous field will not be removed or renamed.

Note that this can not be used to rename an app field to a custom field (only from one custom name to another custom name).

Warning: This will result in a global Jira configuration change.

Select field options

Mapping from select field keys (e.g. "capaType") to their custom configuration, which allows to override the name of individual options or to remove some options.

The name of each option needs to unique among the options for a given field.

When mapped to null, an option is not exposed to the user.

Note this mechanism can not be used to add new options.

Warning: When connected to custom fields in Jira (via the Field names setting), changing this setting will affect the global Jira configuration of those custom fields.

Rename the "Backend" option for the "CAPA type" field to "Server"

{
  "capaType": {
    "BACKEND": "Server"
  }
}

Remove the "Backend" option for the "CAPA type" field

{
  "capaType": {
    "BACKEND": null
  }
}

Item fields

Mapping from standard item type names (e.g. "Requirement") to a configuration of fields to show for such items.

Note that this will affect the corresponding Ketryx screen configurations in Jira.

Configure Requirement item fields

{
  "Requirement": {
    "addedFields": [
      "impactScope",
      {
        "kind": "SYSTEM",
        "fieldKey": "impactCriticality"
      },
      {
        "kind": "CUSTOM",
        "name": "Customer commitment"
      }
    ],
    "removedFields": [
      "relevantStandards",
      "requirementContext"
    ]
  }
}

Custom item fields configuration

Configuration of custom fields to allow them to be synced with Jira and edited them on the Ketryx side.

Fields are not editable on Ketryx by default. Ketryx expects fields to be configured on Jira manually by the user beforehand.

This configuration supersedes Extra field names in the Project item configuration as it has the same baseline functionality, but allows configuring fields to be editable as well.

The type LEGACY_INFER_READONLY treats the field the way the current Extra field names setting treats them. They are only read from Jira, but not written back. When displaying the field its type will be inferred from the data received from Jira. This type is not recommended for new fields and only exists for compatibility reasons.

RICH_TEXT: Rich text fields for formatted content.

SHORT_TEXT: Short text fields for plain text input.

SELECT: Single select fields with predefined options.

MULTI_SELECT: Multi-select fields with predefined options.

DATE: Date picker fields.

DATE_TIME: Date and time picker fields.\

Track various fields in Ketryx

{
  "Acceptance criteria": {
    "type": "LEGACY_INFER_READONLY"
  },
  "Customer commitment date": {
    "type": "LEGACY_INFER_READONLY"
  },
  "Audit notes": {
    "type": "RICH_TEXT",
    "isEditableInKetryx": true,
    "syncToExternalSystem": true
  },
  "Internal feedback": {
    "type": "RICH_TEXT",
    "isEditableInKetryx": false,
    "syncToExternalSystem": true
  },
  "Customer contact data": {
    "type": "SHORT_TEXT",
    "isEditableInKetryx": true,
    "syncToExternalSystem": true
  },
  "Assigned team": {
    "type": "SELECT",
    "isEditableInKetryx": true,
    "syncToExternalSystem": true,
    "options": [
      {
        "value": "Team Red"
      },
      {
        "value": "Team Blue"
      },
      {
        "value": "Team Green",
        "deprecated": true
      }
    ]
  },
  "Supported operating systems": {
    "type": "MULTI_SELECT",
    "isEditableInKetryx": true,
    "syncToExternalSystem": true,
    "options": [
      {
        "value": "Ubuntu 22.04.2"
      },
      {
        "value": "Windows XP",
        "deprecated": true
      },
      {
        "value": "Windows 10"
      },
      {
        "value": "Windows 11"
      }
    ]
  },
  "Development start": {
    "type": "DATE",
    "syncToExternalSystem": true,
    "isEditableInKetryx": true
  },
  "Time of incident": {
    "type": "DATETIME",
    "syncToExternalSystem": true,
    "isEditableInKetryx": true
  }
}

Relation names

How to map relation names to Ketryx relation types when fetching data from Jira. There can potentially be several Jira relation names mapped to the same Ketryx relation.

Note that the direction of the relation in Jira ("inward" vs. "outward") does not matter, as long as the name matches.

Ketryx has a default mapping for relations names, automatically matching Jira links with names that are exactly what is listed in parentheses here to the corresponding Ketryx relation. For example:

• A Jira link called "affects" will be read as the Ketryx relation AFFECTS

• A Jira link called "tests" will be read as the Ketryx relation TESTS

• A Jira link called "is risk-controlled by" will be read as the Ketryx relation IS_RISK_CONTROLLED_BY

Use the name "is child of" instead of the default relation name "has parent"

{
  "HAS_PARENT": [
    "is child of"
  ]
}

Xray

Xray-specific configuration.

This can be used to configure custom status names (other than the default "PASSED" and "FAILED"). For each Ketryx status ("pass", "passWithException", "fail"), a list with an arbitrary number of Xray status names (including potentially an empty list) can be configured.

Configure custom status names together with default names used in Xray

{
  "testStatusNames": {
    "pass": [
      "PASSED",
      "OK"
    ],
    "passWithException": [
      "Passed with note"
    ],
    "fail": [
      "FAILED",
      "Not OK"
    ]
  }
}

Configure custom status names used in Xray

{
  "testStatusNames": {
    "pass": [
      "OK"
    ],
    "passWithException": [
      "Passed with note"
    ],
    "fail": [
      "Not OK"
    ]
  }
}

Custom document types

A list of custom document types to provide better flexibility in managing documents in your projects' EDMSs.

Any types defined here will have their own approval steps (configured on each project's "Approval rules" page) and they will be selectable for all EDMS documents in every project.

NOTE: Changing the "name" of any type will effectively remove the old type and create a new one with the new name. No existing documents with the old type will be automatically transferred over to the new type.

Add custom document types for Manual and SOP

[
  {
    "name": "Manual",
    "shortName": "MAN"
  },
  {
    "name": "SOP",
    "shortName": "SOP"
  }
]

Custom item types

See our reference page on Custom Item Types for more information.

A list of custom item types to provide better flexibility in managing the different types of configuration items in your project.

Any types defined here will have their own approval steps (configured on each project's "Approval rules" page) and they will have the Ketryx default workflow.

NOTE: Changing the "name" of any type will effectively remove the old type and create a new one with the new name. No existing items with the old type will be automatically transferred over to the new type.

NOTE: The given names and short names must be unique.

Add custom item type that can be edited in Ketryx

[
  {
    "lifecycle": "LONG_LIVED",
    "name": "Use Case",
    "shortName": "UC",
    "isEditableInKetryx": true,
    "fields": [
      {
        "kind": "SYSTEM",
        "fieldKey": "description",
        "isEditableInKetryx": true
      },
      {
        "kind": "SYSTEM",
        "fieldKey": "introducedInVersion",
        "isEditableInKetryx": true
      },
      {
        "kind": "SYSTEM",
        "fieldKey": "obsoleteInVersion",
        "isEditableInKetryx": true
      },
      {
        "kind": "SYSTEM",
        "fieldKey": "parentRequirements",
        "isEditableInKetryx": true
      },
      {
        "kind": "SYSTEM",
        "fieldKey": "relevantStandards",
        "isEditableInKetryx": true
      },
      {
        "kind": "SYSTEM",
        "fieldKey": "requirementType",
        "isEditableInKetryx": true
      },
      {
        "kind": "SYSTEM",
        "fieldKey": "requirementContext",
        "isEditableInKetryx": true
      },
      {
        "kind": "SYSTEM",
        "fieldKey": "risks",
        "isEditableInKetryx": true
      },
      {
        "kind": "SYSTEM",
        "fieldKey": "rationale",
        "isEditableInKetryx": true
      },
      {
        "kind": "SYSTEM",
        "fieldKey": "regions",
        "isEditableInKetryx": true
      },
      {
        "kind": "CUSTOM",
        "name": "Custom checkbox field",
        "isEditableInKetryx": true
      },
      {
        "kind": "CUSTOM",
        "name": "Custom paragraph field",
        "isEditableInKetryx": true
      },
      {
        "kind": "CUSTOM",
        "name": "Custom short text field",
        "isEditableInKetryx": true
      },
      {
        "kind": "CUSTOM",
        "name": "Custom date picker field",
        "isEditableInKetryx": true
      },
      {
        "kind": "CUSTOM",
        "name": "Custom radio button field",
        "isEditableInKetryx": true
      },
      {
        "kind": "CUSTOM",
        "name": "Custom date time picker field",
        "isEditableInKetryx": true
      },
      {
        "kind": "CUSTOM",
        "name": "Custom select list single choice field",
        "isEditableInKetryx": true
      },
      {
        "kind": "CUSTOM",
        "name": "Custom select list multiple choices field",
        "isEditableInKetryx": true
      }
    ]
  }
]

Enable Jira configuration

Whether to push Ketryx configurations (item types, screens, workflows) to a connected Jira instance. Individual projects can also be configured to actually use this configuration or not, using the setting Use Ketryx-specific Jira configuration. Enabled by default.

Maintain Jira fields

Whether to maintain Ketryx-defined Jira fields in a connected Jira instance. Enabled by default.

External user email mapping

Map users from external systems to Ketryx users, based on their email address. Supported by select integrations only (currently Jama).

Map external user identifier to Ketryx user email

{
  "[email protected]": "[email protected]"
}

Show withdrawn vulnerabilities

Whether to show withdrawn vulnerabilities in the vulnerability management feature. Disabled by default.

Custom relations

See our reference page on Custom Relations for more information.

A list of custom relations to provide better flexibility in managing the relations between different types of configuration items in your project.

direction is either "upstream" or "downstream". Defaults to "downstream". sourceItemTypes is an array of item type names for the item types that the relation is defined for. targetItemFilter is a KQL filter that is used to find the possible target items for the relation.

NOTE: All fields (including the object key) must be unique for each custom relation.

Custom SW -> HW relation

{
  "SW_USES_HW": {
    "direction": "downstream",
    "fieldName": "Uses HW component",
    "reverseFieldName": "Is used by SW component",
    "relationName": "uses HW",
    "reverseRelationName": "is used by SW",
    "sourceItemTypes": [
      "Software Item Spec"
    ],
    "targetItemFilter": "type:HW",
    "traceabilityWidgetAddLabel": "Add used HW component"
  }
}

Project item configuration

Issue mapping

Mapping from Jira issue types to Ketryx items. This array of mapping entries is traversed in order, and the first match is taken; so there can potentially be several mappings from the same Jira issue type or to the same Ketryx item type (based on different other criteria, such as labels). If there is no match, the Jira issue is not synchronized to Ketryx.

If multiple labels are specified in a single mapping entry, all of them need to match for the mapping to be effective. To specify several labels where any of them should be mapped to a certain item type, use distinct mapping entries.

In addition to inferring a certain item type, field values can also be predefined for each mapping:

• fieldValues defines values that are always set, regardless of any explicit value defined on the Jira issue.

• fieldDefaults defines values that are only set if there is no explicit value defined on the Jira issue.

Each of these properties is an object, mapping internal field keys (e.g. description for built-in fields or extra:My custom field for extra custom fields) to values as they would be retrieved from Jira.

An itemType of CUSTOM can be used to define a custom item type in Ketryx, along with an itemTypeName to specify its actual name. Such custom item types are considered "unchecked", i.e. they are not required to be controlled.

Map issues of type "Folder" or "Epic" to Requirements

[
  {
    "issueType": "Folder",
    "itemType": "REQUIREMENT"
  },
  {
    "issueType": "Epic",
    "itemType": "REQUIREMENT"
  }
]

Map Stories with the "Ketryx" label to Requirements

[
  {
    "issueType": "Story",
    "labels": [
      "Ketryx"
    ],
    "itemType": "REQUIREMENT"
  }
]

Map Stories with the "Ketryx" label to Requirements, and (more specifically) Stories with the label "UseCase" to Requirements with a type of "Use case"

[
  {
    "issueType": "Story",
    "labels": [
      "Ketryx",
      "UseCase"
    ],
    "itemType": "REQUIREMENT",
    "fieldValues": {
      "requirementType": {
        "value": "Use case"
      }
    }
  },
  {
    "issueType": "Story",
    "labels": [
      "Ketryx"
    ],
    "itemType": "REQUIREMENT"
  }
]

Map the native Jira parent-child hierarchy field per child item type

[
  {
    "issueType": "Epic",
    "itemType": "REQUIREMENT"
  },
  {
    "issueType": "Story",
    "itemType": "REQUIREMENT",
    "fields": {
      "parent": {
        "type": "references",
        "relationType": "HAS_PARENT",
        "targetSystem": "Jira"
      }
    }
  }
]

Status mapping

Mapping from Jira status names to Ketryx item states (OPEN, REOPENED, IN_PROGRESS, RESOLVED, or CLOSED).

Map the status "Backlog" to the Ketryx state Open, and "Done" to Resolved

{
  "Backlog": "OPEN",
  "Done": "RESOLVED"
}

Jira field mapping

Mapping between Jira field names and Ketryx system field keys (or ignoring certain Jira field values).

Jira fields are identified by their user-facing label, whereas Ketryx fields are identified by their internal field key (e.g. initialOccurrenceProbabilityText), similarly to the Issue mapping setting.

This affects both reading fields from Jira as well as writing data from Ketryx to Jira, if possible. However, note that some fields (e.g. various risk evaluation fields) are inherently "read-only" as far as Jira is concerned, i.e. Ketryx will not write values to Jira for them, regardless of this configuration.

This can be used to read field values from Jira that would otherwise be ignored, such as risk evaluation fields which are usually edited in Ketryx. This may be useful for an initial data import, but is not recommended afterwards, since edits in Ketryx may be overwritten by those Jira fields.

This is similar to the setting Field names, but only affects reading and writing values, without affecting the Jira screen configuration or how fields are displayed in Ketryx. Moreover, this setting can be changed at the project level, whereas Field names is only configurable at the organization level.

This setting may also be useful in cases where a configured custom item field editable in Ketryx should only be editable in Ketryx, and not in Jira (mapping the Jira custom field to null to ignore any Jira value).

Warning: Changing the field mapping might have wide-reaching effects, resulting in items transitioning out of their controlled state.

Note: For changing the mapping of version fields, use the setting Version fields. To read custom fields from Jira as custom fields in Ketryx (rather than as system fields), use the setting Extra field names.

Read risk evaluation fields from Jira

{
  "Initial likelihood of occurrence (P1)": "initialOccurrenceProbabilityText",
  "Initial likelihood of harm (P2)": "initialHarmProbabilityText",
  "Initial severity": "initialSeverityText",
  "Initial risk evaluation": "initialRiskEvaluation",
  "Residual likelihood of occurrence (P1)": "residualOccurrenceProbabilityText",
  "Residual likelihood of harm (P2)": "residualHarmProbabilityText",
  "Residual severity": "residualSeverityText",
  "Residual risk evaluation": "residualRiskEvaluation"
}

Read a custom description field from Jira

{
  "My description field": "description"
}

Ignore a certain field value from Jira

{
  "My custom field": null
}

Jira widget display

Configuration to override the default display of Ketryx widgets within Jira. This includes the Approval, Traceability and Risk widget.

Updating this setting requires a project sync within Ketryx to take effect.

Enable the risk widget only for a particular custom Risk type

{
  "risksIssueTypeNames": [
    "Risk",
    "My Custom Risk type"
  ]
}

Enable the traceability and approvals widgets for chosen Item Types

{
  "approvalsIssueTypeNames": [
    "Customer Requirement (migrated)",
    "SRS (migrated)",
    "Security and Privacy",
    "FMEA (SaMD Product)",
    "Security-Privacy-Assessment",
    "XRay Test",
    "Test Execution",
    "Defect"
  ],
  "traceabilityIssueTypeNames": [
    "Customer Requirement (migrated)",
    "SRS (migrated)",
    "Security and Privacy",
    "Security-Privacy-Assessment",
    "FMEA (SaMD Product)",
    "XRay Test",
    "Test Execution",
    "Defect"
  ]
}

In order to configure the Jira widget display setting for specific fields correctly, navigate to Jira Settings > Work Types, find the applicable Work Type names, and populate them in the JSON object as shown above. NOTE: if using this setting to override the default display, the user will now need to explicitly state every Work Type that they want to display the widgets, even if the Work Type previously had it by default.

Traceability widget configuration

Configuration of the traceability widget, which allows to display the details of the selected item

Enable detailed view with specific fields

{
  "detailView": {
    "enabled": true,
    "fields": [
      {
        "fieldKey": "description",
        "kind": "SYSTEM"
      },
      {
        "name": "Custom Field 1",
        "kind": "CUSTOM"
      }
    ],
    "extraFields": [
      "Extra Field 1"
    ]
  }
}

Approval workflow

Mapping from item types (enum values such as 'REQUIREMENT', 'CUSTOM' or plain-text values such as 'Requirement', 'Folder') and Jira status names (e.g. 'Open', 'New') to approval workflow customizations. Note that when overriding some settings for an item type and status, no other specific defaults will be applied, so all desired settings should be specified explicitly. Each entry can have the following properties:

• instructionText: Text to display to the user in the Approvals widget for this status.

• isApprovable: Whether to allow approvals for this status.

• approvalMeaning: The approval meaning when approving an item with this status.

• requiredFieldNames: Names of required fields before an item with this status can be approved. This is a list of human-readable field names (e.g. 'Description', 'My extra custom field').

• approvalGroups: Approval groups for this step in the workflow. The groups are referenced by their human-readable name (e.g. 'R&D Leads'), and they need to be a subset of the groups used in the full approval rules for the item type. A special entry '#owner' refers to the owner (= assignee) of an item. If not defined, this defaults to the full approval rules for the item type.

• shouldTransitionWhenApproved: Whether items with this status should be transitioned by Ketryx upon approval. Upon full approval, a new record is created; the status of that new record is set to approvedTransitionStatus if defined (otherwise the status remains the same), and it will be a controlled record depending on the new status' isControlled setting. By default, this is true for the 'Resolved' status.

• approvedTransitionStatus: The status to transition to upon approval, if shouldTransitionWhenApproved is true. If this is set to null, no state transition will occur upon full approval, i.e. there will be a new (system-created) record with the same status as before. By default, this is 'Closed' for the 'Resolved' status, i.e. upon full approval of a Resolved item, it is transitioned to the Closed status.

• rejectedTransitionStatus: The status to transition to upon rejection. If this is set to null, no state transition will occur upon rejection, i.e. there will be a new (system-created) record with the same status as before. By default, upon rejection of a Resolved item, it is transitioned to the Open status.

• invalidatedTransitionStatus: The status to transition to from this state, in case the data of the record is changed or (if activated) a design input changes. If this is set to null, no state transition will occur even if data changes. By default, this is set to 'Resolved' for the 'Closed' status, i.e. an item is "unclosed" by transitioning it from Closed back to Resolved. Changes to fields specified in uncontrolledFieldNames are ignored and do not result in an invalidation transition.

• isControlled: Whether this status is considered a controlled state. When transitioning into this state (after approval), the new record's isControlled will be set accordingly. By default, this is true for the 'Closed' status.

• shouldLockSourceItem: When transitioning into this state, lock the source item in the connected system. Only supported for Jama.

• keepApprovalsWhenTransitionedTo: When transitioning from this status to one of the specified status, approvals will be "carried over" to the new status, as long as only the status changed (but no other fields). This can be used to implement a workflow such as In Progress -> Waiting for Approval -> Approved where the owner approves and triggers the first transition, while another approval happens in another transition (but both approvals still count towards the overall approval state). When set to a literal '*', transitions from this status will always keep approvals.

• acceptApproval: A list of external systems of which approvals should be accepted as controlled records. An item is considered controlled externally when it reaches a status configured as controlled, and the external system is listed in this setting. Only supported for Jama.

• uncontrolledFieldNames: Names of fields to consider as "uncontrolled" when keeping approvals after a state transition, i.e. if keepApprovalsWhenTransitionedTo is defined. The state and status names are always ignored, i.e. approvals are kept as long as only state / status name change. Other field names can be added to this list, e.g. to allow users to set fields during a status transition, without invalidating previous approvals. When set to a literal '*', all fields are considered uncontrolled. This is a list of human-readable field names (e.g. 'Description', 'My custom field').

Enforce that Requirements have a required (extra) field "Acceptance Criteria" before they can be approved

{
  "REQUIREMENT": {
    "Resolved": {
      "isApprovable": true,
      "approvalMeaning": "REVIEWED",
      "requiredFieldNames": [
        "Acceptance Criteria"
      ],
      "approvedTransitionStatus": "Closed",
      "invalidatedTransitionStatus": "Resolved",
      "shouldTransitionWhenApproved": true
    }
  }
}

Jama-integrated workflows

Approve in Ketryx and transition and lock the Jama item

{
  "REQUIREMENT": {
    "Resolved": {
      "isApprovable": true,
      "approvalMeaning": "REVIEWED",
      "approvedTransitionStatus": "Closed",
      "shouldTransitionWhenApproved": true
    },
    "Closed": {
      "isControlled": true,
      "shouldLockSourceItem": true
    }
  }
}

Transition in Jama and control the Ketryx item without further approvals

{
  "REQUIREMENT": {
    "Closed": {
      "isControlled": true,
      "acceptApproval": [ "Jama" ]
    }
  }
}

This is based on the mapped Jama item status field. It is recommended to setup Jama approval workflows for each Jama item type that automatically transition items to the corresponding Jama state once a review is completed. Ketryx will then read those as controlled records and not require further approvals.

Approval rules

Custom approval rule overrides, allowing an arbitrary KQL filter. These are applied after the general approval rules of the project (defined by the user) and the backend customizations defined by approvalWorkflow, i.e. these approvalRules are the most specific setting.

Adjust approval groups for Requirements of type "Intended use"

[
  {
    "itemFilter": "type:RQ and !\"Requirement type\":\"Intended use\"",
    "groupNamesToRemove": [
      "Quality Managers"
    ],
    "groupNamesToKeep": [
      "R&D Leads"
    ]
  }
]

Electronic signature item types

Item types (standard names such as "Requirement" or custom names such as "Folder") that require an electronic signature. The default would be ["Risk", "Test Case", "Test Execution", "Test Plan"].

Only require electronic signatures on Risk items

[
  "Risk"
]

Enable Assistant Sidebar

Whether to enable the Assistant sidebar. Enabled by default.

Enable AI

Whether to enable AI-based features, particularly the AI-based item assistant and the 'Write AI text' button in the 'Create item' dialog. This only has an actual effect if AI usage is allowed at the organization level. Enabled by default.

Enable enhanced AI-based item creation and editing

Whether the Assistant should automatically identify and suggest items related to new items suggested or edited by it, in response to a user query. Enabling this feature will prolong response time. This only has an actual effect if AI usage is allowed at the organization level. Disabled by default.

AI prompt suggestions

Predefined prompt groups for the Assistant sidebar. Each group represents a expandable selection for defined templates.

Use custom prompt group with a set of templates

[
  {
    "name": "Search & Find",
    "suggestions": [
      {
        "label": "Find all anomalies with high criticality",
        "prompt": "List me all anomalies with 'Impact criticality' set to 'High'"
      }
    ]
  }
]

AI feature configuration

Custom configuration of the AI-based features such as the item assistant.

Use a custom OpenAI instance on Azure

{
  "providers": {
    "openAi": {
      "endpointUrl": "https://instance-yourcompany.openai.azure.com/openai/deployments/DeploymentYourCompanyGpt35t16k",
      "apiKey": "sk-proj-XXXXXXXXxxxxxxxxXXXXXXXXxxxxxxxxXXXXXXXXxxxxxxxx"
    }
  }
}

Use a custom OpenAI endpoint

{
  "providers": {
    "openAi": {
      "endpointUrl": "https://api.openai.com/v1",
      "apiKey": "sk-proj-XXXXXXXXxxxxxxxxXXXXXXXXxxxxxxxxXXXXXXXXxxxxxxxx"
    }
  }
}

Enable version deletion

Whether versions can be deleted by users with the appropriate permissions. Enabled by default.

Enable item invalidation

Whether to enable invalidation of items if controlled fields change, based on invalidatedTransitionStatus in the workflow configuration (by default, Closed items are transitioned back to Resolved for invalidation). If this is not set or null, invalidation is enabled unless the project is in observe-only mode (not using the predefined Ketryx workflows).

Removal status names

Status names to interpret as removal/obsolescence of an item w.r.t. releases, similarly to deleted items. Defaults to an empty list.

Treat items with the status of "Cancel" as removed/obsolete

[
  "Cancel"
]

Deletion status name (controlled)

Status name to represent deleted items in a controlled state. This status is set by Ketryx when a deletion is detected and does not need to be approved. Defaults to "Closed".

Deletion status name (uncontrolled)

Status name to represent deleted items in an uncontrolled state. This status is set by Ketryx when a deletion is detected that still needs to be approved. Defaults to "Resolved".

Uncontrolled field names

Names of fields to ignore w.r.t. the controlled state of a record and its content hash. Changing these fields does not influence the record's content hash and does not trigger a transition back into an uncontrolled state.

Ketryx will still create a new record with the new value, but the status will remain the same (unless other, controlled fields changed as well).

Allow setting the "Document ID" field even after an item is fully approved

[
  "Document ID"
]

Extra field names

List of extra custom field names to read from Jira. These should be defined as custom fields in Jira and added to the desired screens (Ketryx will not perform this Jira configuration automatically). Extra fields can also refer to any field from source systems other than Jira, like Polarion or Jama, when a field cannot be mapped to a system field.

This is superseded by Custom item fields configuration which allows for more fine-grained configuration.

Track the extra fields "Acceptance Criteria" and "Source"

[
  "Acceptance Criteria",
  "Source"
]

Unchecked items filter

KQL filter for "unchecked" items, i.e. items that do not need to be controlled before a version can be released. By default, no items are considered unchecked.

Do not require Anomalies with an Environment of "internal" to be controlled

"Environment:\"internal\""

Deferred items filter

KQL filter for deferred items (anomalies). By default (if not specified), all Anomalies with a non-empty Rationale for deferring resolution will be considered deferred. Deferred items do not need to be in a controlled state (like unchecked items).

Invalid items filters

KQL filters to determine invalid items, along with error messages to show for them. Invalid items that are active in a version block the release of that version.

Enforce Anomalies with a Resolution of "Duplicate" to have a status of either "Done" or "Cancel"

[
  {
    "filter": "type:Anomaly and Resolution:\"Duplicate\" and not status:(Done, Cancel)",
    "message": "Duplicate anomalies need to have a status of either Done or Cancel"
  }
]

Enforce that all Test Cases that are risk controls are included in the test plan

[
  {
    "filter": "TC and RC and not intestplan:selected",
    "message": "All tests that are risk controls need to be in the test plan"
  }
]

Ignored test executions filter

Filter for Test Executions to ignore for the release test status. Just like "redundant" Test Executions (that are superseded by a later Test Execution), these are still shown in the Items page, but not elsewhere.

Use Test Executions only based on Test Plan

Whether to associate Test Executions with versions only based on (Xray) Test Plan items, but not based on their version field. This is off by default, i.e. a Test Execution's version field (Introduced in version) is considered, and only if that is not set, it is associated with a version based on containing Test Plans.

Enable automatic risk item updates on risk configuration change

When enabled, Ketryx will make sure to keep all Risk items up-to-date with any risk configuration changes by creating new item records (e.g. updating all the relevant computed initial / residual risk analysis values). Please note that controlled risks may require re-approval after an configuration update. This setting is enabled by default.

Build documents to be tracked for each project build

When defined, Ketryx will detect build documents in project builds that contain build artifacts with the configured filenames.

Build documents will show up on the commits history page and release documents page.

By default, Ketryx will only allow release approval when all defined build documents have been uploaded for a given version. This behavior can be disabled via the "Require uploaded build documents" Release controls setting.

Configure different report build documents relevant for a release

[
  {
    "id": "owasp-report",
    "filename": "owasp-report.json"
  },
  {
    "id": "code-coverage-report",
    "filename": "code-coverage-report.pdf"
  }
] 

Traceability configuration

Configuration for the traceability behavior. The Ketryx RTM currently offers two different engines for configuring the traceability: v2 (legacy), which comes with slightly adjustable pre-configured traceability presets, and v3, which allows much more detailed customizations such as configurable design and testing columns, tracing rules, traceability checks and much more.

(RTM v3) Enable the new RTM v3 mechanism. Defaults to the project's schema config to determine the traceability behavior (equivalent to the v2 presets)

{
  "version": "3"
}

(RTM v3) Full example for a project using the full schema config tracing use-cases, design inputs (Requirements), design outputs (SW/HW specifications), verification tests (testing design outputs) and validation tests (testing design inputs)

{
  "version": "3",
  "rtmApprovalEnabled": false,
  "enforceGreenCheck": true,
  "defaultColumnId": "designInput",
  "statusDefinitions": {
    "REQUIREMENT_MISSING": {
      "level": "ERROR"
    },
    "SPEC_MISSING": {
      "level": "ERROR"
    },
    "MANUAL_TEST_EXECUTION_MISSING": {
      "level": "ERROR"
    },
    "TEST_EXECUTION_MISSING": {
      "level": "ERROR"
    },
    "TEST_EXECUTION_MISSING_RESULT": {
      "level": "ERROR"
    },
    "VERIFICATION_TEST_MISSING": {
      "level": "ERROR"
    },
    "VALIDATION_TEST_MISSING": {
      "level": "ERROR"
    },
    "TEST_EXECUTION_FAILED": {
      "level": "ERROR"
    },
    "NOT_INCLUDED_IN_TEST_PLAN": {
      "level": "MUTED"
    },
    "TEST_EXECUTION_NOT_CONTROLLED": {
      "level": "WARNING"
    },
    "RISK_NOT_CONTROLLED": {
      "level": "WARNING"
    },
    "NOT_CONTROLLED": {
      "level": "WARNING"
    }
  },
  "rowStatusMessages": {
    "REQUIREMENT_MISSING": {
      "message": {
        "subject": "Use case",
        "description": "not covered by a design input."
      }
    },
    "SPEC_MISSING": {
      "message": {
        "subject": "Design input",
        "description": "not covered by a design output."
      }
    },
    "VERIFICATION_TEST_MISSING": {
      "message": {
        "subject": "Design output",
        "description": "not covered by a verification test."
      }
    },
    "VALIDATION_TEST_MISSING": {
      "message": {
        "subject": "Design input",
        "description": "not covered by a validation test."
      }
    },
    "MANUAL_TEST_EXECUTION_MISSING": {
      "message": {
        "subject": "Test Case",
        "description": "without manual test executions for automated tests."
      }
    },
    "TEST_EXECUTION_MISSING_RESULT": {
      "message": {
        "subject": "Test Execution",
        "description": "without a test result."
      }
    },
    "TEST_EXECUTION_MISSING": {
      "message": {
        "subject": "Test Case",
        "description": "without a test execution."
      }
    },
    "TEST_EXECUTION_FAILED": {
      "message": {
        "subject": "Test Execution",
        "description": "failed."
      }
    },
    "NOT_CONTROLLED": {
      "aliases": [
        "RISK_NOT_CONTROLLED",
        "TEST_EXECUTION_NOT_CONTROLLED"
      ],
      "message": {
        "subject": "Item",
        "description": "not fully approved yet."
      }
    }
  },
  "cellStatusMessages": [
    {
      "if": [
        "REQUIREMENT_MISSING"
      ],
      "message": "Requirement missing"
    },
    {
      "if": [
        "SPEC_MISSING",
        "VERIFICATION_TEST_MISSING",
        "VALIDATION_TEST_MISSING"
      ],
      "message": "Specification and test cases missing"
    },
    {
      "if": [
        "SPEC_MISSING",
        "VERIFICATION_TEST_MISSING"
      ],
      "message": "Specification and test case missing"
    },
    {
      "if": [
        "SPEC_MISSING",
        "VALIDATION_TEST_MISSING"
      ],
      "message": "Specification and test case missing"
    },
    {
      "if": [
        "SPEC_MISSING"
      ],
      "message": "Specification missing"
    },
    {
      "if": [
        "VERIFICATION_TEST_MISSING"
      ],
      "message": "Verification test case missing"
    },
    {
      "if": [
        "VALIDATION_TEST_MISSING"
      ],
      "message": "Validation test case missing"
    },
    {
      "if": [
        "NOT_INCLUDED_IN_TEST_PLAN"
      ],
      "message": "Not included in test plan"
    },
    {
      "if": [
        "TEST_EXECUTION_MISSING_RESULT"
      ],
      "message": "Test execution result missing"
    },
    {
      "if": [
        "TEST_EXECUTION_MISSING"
      ],
      "message": "Test execution missing"
    },
    {
      "if": [
        "MANUAL_TEST_EXECUTION_MISSING"
      ],
      "message": "Manual test execution missing for automated test"
    },
    {
      "if": [
        "TEST_EXECUTION_FAILED"
      ],
      "message": "Test execution failed"
    },
    {
      "if": [
        "TEST_EXECUTION_NOT_CONTROLLED"
      ],
      "message": "Missing approval for Manual Test Execution"
    },
    {
      "if": [
        "TEST_EXECUTION_NOT_CONTROLLED"
      ],
      "message": "Missing approval for Manual Test Execution"
    },
    {
      "if": [
        "RISK_NOT_CONTROLLED"
      ],
      "message": "Missing approval for Risk"
    },
    {
      "if": [
        "NOT_CONTROLLED"
      ],
      "message": "Missing approval"
    }
  ],
  "columns": [
    {
      "columnId": "useCase",
      "title": "Use cases",
      "kind": "design",
      "itemFilter": "type:RQ and \"Requirement type\":\"Use case\""
    },
    {
      "columnId": "designInput",
      "title": "Design Input",
      "kind": "design",
      "itemFilter": "type:RQ and not \"Requirement type\":\"Use case\" and not \"Requirement type\":\"Intended use\"",
      "relations": [
        {
          "kind": "indirect",
          "relationType": "HAS_PARENT",
          "referencedColumnId": "useCase"
        }
      ]
    },
    {
      "columnId": "designOutput",
      "title": "Design Output",
      "kind": "design",
      "itemFilter": "type:SW or type:HW",
      "relations": [
        {
          "kind": "direct",
          "relationType": "FULFILLS",
          "referencedColumnId": "designInput"
        }
      ]
    },
    {
      "columnId": "verificationTest",
      "title": "Verification test",
      "kind": "testing",
      "testedItemFilter": "type:SW or type:HW",
      "referencedColumnIds": [
        "designOutput"
      ]
    },
    {
      "columnId": "validationTest",
      "title": "Validation test",
      "kind": "testing",
      "testedItemFilter": "type:RQ",
      "referencedColumnIds": [
        "designInput"
      ]
    }
  ],
  "checks": [
    {
      "checkId": "useCasesCovered",
      "kind": "coverage",
      "title": "Use cases",
      "subtitle": "Covered by design input",
      "filterDescription": "use cases not covered by a design input",
      "columnIds": [
        "useCase"
      ],
      "coveredByColumnId": "designInput",
      "checkCrossReferences": true,
      "onFail": {
        "status": "REQUIREMENT_MISSING"
      }
    },
    {
      "checkId": "designInputsCovered",
      "kind": "coverage",
      "title": "Design input",
      "subtitle": "Covered by design outputs",
      "filterDescription": "design inputs not covered by a design output",
      "columnIds": [
        "designInput"
      ],
      "coveredByColumnId": "designOutput",
      "checkCrossReferences": true,
      "onFail": {
        "status": "SPEC_MISSING"
      }
    },
    {
      "checkId": "verificationTestCoverage",
      "kind": "coverage",
      "title": "Verification",
      "subtitle": "Design outputs covered by tests",
      "filterDescription": "design outputs not covered by a verification test case",
      "columnIds": [
        "designOutput"
      ],
      "coveredByColumnId": "verificationTest",
      "checkCrossReferences": true,
      "onFail": {
        "status": "VERIFICATION_TEST_MISSING"
      }
    },
    {
      "checkId": "validationTestCoverage",
      "kind": "coverage",
      "title": "Validation",
      "subtitle": "Design inputs covered by tests",
      "filterDescription": "design inputs not covered by a validation test case",
      "columnIds": [
        "designInput"
      ],
      "coveredByColumnId": "validationTest",
      "checkCrossReferences": true,
      "onFail": {
        "status": "VALIDATION_TEST_MISSING"
      }
    },
    {
      "checkId": "testExecutions",
      "kind": "testExecutions",
      "title": "Test executions",
      "subtitle": "Created within test plan",
      "filterDescription": "test cases missing a test execution or test result",
      "onMissingManualExecution": {
        "status": "MANUAL_TEST_EXECUTION_MISSING"
      },
      "onMissingExecution": {
        "status": "TEST_EXECUTION_MISSING"
      },
      "onMissingExecutionResult": {
        "status": "TEST_EXECUTION_MISSING_RESULT"
      },
      "onNotInTestPlan": {
        "status": "NOT_INCLUDED_IN_TEST_PLAN"
      }
    },
    {
      "checkId": "failedTests",
      "kind": "failedTests",
      "title": "Failing tests",
      "subtitle": "Within test plan",
      "filterDescription": "failing test executions",
      "onFail": {
        "status": "TEST_EXECUTION_FAILED"
      }
    },
    {
      "checkId": "allItemsControlled",
      "kind": "controlled",
      "title": "Controlled",
      "subtitle": "Items fully approved",
      "filterDescription": "uncontrolled items that need to be approved",
      "checkCrossReferences": true,
      "onTestExecutionNotControlled": {
        "status": "TEST_EXECUTION_NOT_CONTROLLED"
      },
      "onRiskNotControlled": {
        "status": "RISK_NOT_CONTROLLED"
      },
      "onItemNotControlled": {
        "status": "NOT_CONTROLLED"
      }
    }
  ],
  "columnForTestsWithoutTestedItem": "validationTest"
}

(RTM v2) Trace "Use case" requirements to other requirements to specs to tests (overriding the behavior from the project's schema config)

{
  "mode": "SYSTEM_REQUIREMENT_AND_SPECIFICATION"
}

(RTM v2) Only require validation of requirements (overriding the behavior from the project's schema config)

{
  "mode": "REQUIREMENT_VALIDATION_ONLY"
}

(RTM v2) Add "Intended use" requirements to the first column (rather than ignoring them, which would be the default)

{
  "mode": "SYSTEM_REQUIREMENT_AND_SPECIFICATION",
  "columnNames": {
    "USE_CASE_COLUMN": "User requirement"
  },
  "useCaseColumnRequirementTypes": [
    "USE_CASE",
    "INTENDED_USE"
  ],
  "ignoredRequirementTypes": []
}

Enable the RTM approval workflow for the traceability page

{
  "rtmApprovalEnabled": true
}

Additional traceability configurations

Other traceability configurations that are selectable in addition to the default configuration.

enforceGreenCheck will make these additional traceability configurations also affect the release checklist.

Two additional traceability configs

[
  {
    "name": "RTM v3 standard",
    "config": {
      "version": "3"
    },
    "enforceGreenCheck": true
  },
  {
    "name": "RTM v3 full",
    "config": {
      "version": "3",
      "rtmApprovalEnabled": false,
      "enforceGreenCheck": true,
      "defaultColumnId": "designInput",
      "statusDefinitions": {
        "REQUIREMENT_MISSING": {
          "level": "ERROR"
        },
        "SPEC_MISSING": {
          "level": "ERROR"
        },
        "MANUAL_TEST_EXECUTION_MISSING": {
          "level": "ERROR"
        },
        "TEST_EXECUTION_MISSING": {
          "level": "ERROR"
        },
        "TEST_EXECUTION_MISSING_RESULT": {
          "level": "ERROR"
        },
        "VERIFICATION_TEST_MISSING": {
          "level": "ERROR"
        },
        "VALIDATION_TEST_MISSING": {
          "level": "ERROR"
        },
        "TEST_EXECUTION_FAILED": {
          "level": "ERROR"
        },
        "NOT_INCLUDED_IN_TEST_PLAN": {
          "level": "MUTED"
        },
        "TEST_EXECUTION_NOT_CONTROLLED": {
          "level": "WARNING"
        },
        "RISK_NOT_CONTROLLED": {
          "level": "WARNING"
        },
        "NOT_CONTROLLED": {
          "level": "WARNING"
        }
      },
      "rowStatusMessages": {
        "REQUIREMENT_MISSING": {
          "message": {
            "subject": "Use case",
            "description": "not covered by a design input."
          }
        },
        "SPEC_MISSING": {
          "message": {
            "subject": "Design input",
            "description": "not covered by a design output."
          }
        },
        "VERIFICATION_TEST_MISSING": {
          "message": {
            "subject": "Design output",
            "description": "not covered by a verification test."
          }
        },
        "VALIDATION_TEST_MISSING": {
          "message": {
            "subject": "Design input",
            "description": "not covered by a validation test."
          }
        },
        "MANUAL_TEST_EXECUTION_MISSING": {
          "message": {
            "subject": "Test Case",
            "description": "without manual test executions for automated tests."
          }
        },
        "TEST_EXECUTION_MISSING_RESULT": {
          "message": {
            "subject": "Test Execution",
            "description": "without a test result."
          }
        },
        "TEST_EXECUTION_MISSING": {
          "message": {
            "subject": "Test Case",
            "description": "without a test execution."
          }
        },
        "TEST_EXECUTION_FAILED": {
          "message": {
            "subject": "Test Execution",
            "description": "failed."
          }
        },
        "NOT_CONTROLLED": {
          "aliases": [
            "RISK_NOT_CONTROLLED",
            "TEST_EXECUTION_NOT_CONTROLLED"
          ],
          "message": {
            "subject": "Item",
            "description": "not fully approved yet."
          }
        }
      },
      "cellStatusMessages": [
        {
          "if": [
            "REQUIREMENT_MISSING"
          ],
          "message": "Requirement missing"
        },
        {
          "if": [
            "SPEC_MISSING",
            "VERIFICATION_TEST_MISSING",
            "VALIDATION_TEST_MISSING"
          ],
          "message": "Specification and test cases missing"
        },
        {
          "if": [
            "SPEC_MISSING",
            "VERIFICATION_TEST_MISSING"
          ],
          "message": "Specification and test case missing"
        },
        {
          "if": [
            "SPEC_MISSING",
            "VALIDATION_TEST_MISSING"
          ],
          "message": "Specification and test case missing"
        },
        {
          "if": [
            "SPEC_MISSING"
          ],
          "message": "Specification missing"
        },
        {
          "if": [
            "VERIFICATION_TEST_MISSING"
          ],
          "message": "Verification test case missing"
        },
        {
          "if": [
            "VALIDATION_TEST_MISSING"
          ],
          "message": "Validation test case missing"
        },
        {
          "if": [
            "NOT_INCLUDED_IN_TEST_PLAN"
          ],
          "message": "Not included in test plan"
        },
        {
          "if": [
            "TEST_EXECUTION_MISSING_RESULT"
          ],
          "message": "Test execution result missing"
        },
        {
          "if": [
            "TEST_EXECUTION_MISSING"
          ],
          "message": "Test execution missing"
        },
        {
          "if": [
            "MANUAL_TEST_EXECUTION_MISSING"
          ],
          "message": "Manual test execution missing for automated test"
        },
        {
          "if": [
            "TEST_EXECUTION_FAILED"
          ],
          "message": "Test execution failed"
        },
        {
          "if": [
            "TEST_EXECUTION_NOT_CONTROLLED"
          ],
          "message": "Missing approval for Manual Test Execution"
        },
        {
          "if": [
            "TEST_EXECUTION_NOT_CONTROLLED"
          ],
          "message": "Missing approval for Manual Test Execution"
        },
        {
          "if": [
            "RISK_NOT_CONTROLLED"
          ],
          "message": "Missing approval for Risk"
        },
        {
          "if": [
            "NOT_CONTROLLED"
          ],
          "message": "Missing approval"
        }
      ],
      "columns": [
        {
          "columnId": "useCase",
          "title": "Use cases",
          "kind": "design",
          "itemFilter": "type:RQ and \"Requirement type\":\"Use case\""
        },
        {
          "columnId": "designInput",
          "title": "Design Input",
          "kind": "design",
          "itemFilter": "type:RQ and not \"Requirement type\":\"Use case\" and not \"Requirement type\":\"Intended use\"",
          "relations": [
            {
              "kind": "indirect",
              "relationType": "HAS_PARENT",
              "referencedColumnId": "useCase"
            }
          ]
        },
        {
          "columnId": "designOutput",
          "title": "Design Output",
          "kind": "design",
          "itemFilter": "type:SW or type:HW",
          "relations": [
            {
              "kind": "direct",
              "relationType": "FULFILLS",
              "referencedColumnId": "designInput"
            }
          ]
        },
        {
          "columnId": "verificationTest",
          "title": "Verification test",
          "kind": "testing",
          "testedItemFilter": "type:SW or type:HW",
          "referencedColumnIds": [
            "designOutput"
          ]
        },
        {
          "columnId": "validationTest",
          "title": "Validation test",
          "kind": "testing",
          "testedItemFilter": "type:RQ",
          "referencedColumnIds": [
            "designInput"
          ]
        }
      ],
      "checks": [
        {
          "checkId": "useCasesCovered",
          "kind": "coverage",
          "title": "Use cases",
          "subtitle": "Covered by design input",
          "filterDescription": "use cases not covered by a design input",
          "columnIds": [
            "useCase"
          ],
          "coveredByColumnId": "designInput",
          "checkCrossReferences": true,
          "onFail": {
            "status": "REQUIREMENT_MISSING"
          }
        },
        {
          "checkId": "designInputsCovered",
          "kind": "coverage",
          "title": "Design input",
          "subtitle": "Covered by design outputs",
          "filterDescription": "design inputs not covered by a design output",
          "columnIds": [
            "designInput"
          ],
          "coveredByColumnId": "designOutput",
          "checkCrossReferences": true,
          "onFail": {
            "status": "SPEC_MISSING"
          }
        },
        {
          "checkId": "verificationTestCoverage",
          "kind": "coverage",
          "title": "Verification",
          "subtitle": "Design outputs covered by tests",
          "filterDescription": "design outputs not covered by a verification test case",
          "columnIds": [
            "designOutput"
          ],
          "coveredByColumnId": "verificationTest",
          "checkCrossReferences": true,
          "onFail": {
            "status": "VERIFICATION_TEST_MISSING"
          }
        },
        {
          "checkId": "validationTestCoverage",
          "kind": "coverage",
          "title": "Validation",
          "subtitle": "Design inputs covered by tests",
          "filterDescription": "design inputs not covered by a validation test case",
          "columnIds": [
            "designInput"
          ],
          "coveredByColumnId": "validationTest",
          "checkCrossReferences": true,
          "onFail": {
            "status": "VALIDATION_TEST_MISSING"
          }
        },
        {
          "checkId": "testExecutions",
          "kind": "testExecutions",
          "title": "Test executions",
          "subtitle": "Created within test plan",
          "filterDescription": "test cases missing a test execution or test result",
          "onMissingManualExecution": {
            "status": "MANUAL_TEST_EXECUTION_MISSING"
          },
          "onMissingExecution": {
            "status": "TEST_EXECUTION_MISSING"
          },
          "onMissingExecutionResult": {
            "status": "TEST_EXECUTION_MISSING_RESULT"
          },
          "onNotInTestPlan": {
            "status": "NOT_INCLUDED_IN_TEST_PLAN"
          }
        },
        {
          "checkId": "failedTests",
          "kind": "failedTests",
          "title": "Failing tests",
          "subtitle": "Within test plan",
          "filterDescription": "failing test executions",
          "onFail": {
            "status": "TEST_EXECUTION_FAILED"
          }
        },
        {
          "checkId": "allItemsControlled",
          "kind": "controlled",
          "title": "Controlled",
          "subtitle": "Items fully approved",
          "filterDescription": "uncontrolled items that need to be approved",
          "checkCrossReferences": true,
          "onTestExecutionNotControlled": {
            "status": "TEST_EXECUTION_NOT_CONTROLLED"
          },
          "onRiskNotControlled": {
            "status": "RISK_NOT_CONTROLLED"
          },
          "onItemNotControlled": {
            "status": "NOT_CONTROLLED"
          }
        }
      ],
      "columnForTestsWithoutTestedItem": "validationTest"
    },
    "enforceGreenCheck": false
  }
]

Allow item transition

Whether to allow items to be transitioned from the Ketryx side. By default (if not defined or null), transitions are allowed based on the project's observe-only flag: In observe-only mode, transitions are not allowed; otherwise they are allowed.

Note that, currently, transitions are only supported for built-in Ketryx statuses and workflows. Using different status names or workflows in connected systems (such as Jira) might be a reason to disable this.

Allow item creation

Whether to allow items to be created from the Ketryx side (e.g. Risks, Test Executions, other items). By default (if not defined or null), item creation is allowed based on the project's observe-only flag: In observe-only mode, item creation is not allowed; otherwise it is allowed.

Note that constraints configured in connected systems (such as custom item creation screens and field validations in Jira) are not enforced by Ketryx. Using such constraints might be a reason to disable this.

Note that this setting also affects whether items can be created via the Ketryx traceability widget in the connected systems (e.g. Jira).

Allow item editing

Whether to allow items to be edited from the Ketryx side (e.g. Risks, Test Executions, other items). By default (if not defined or null), item editing is allowed based on the project's observe-only flag: In observe-only mode, item editing is not allowed; otherwise it is allowed.

Note that constraints configured in connected systems (such as custom item creation screens and field validations in Jira) are not enforced by Ketryx. Using such constraints might be a reason to disable this.

Note that this setting also affects whether existing items can be linked via the Ketryx traceability widget in the connected systems (e.g. Jira).

Item editing rules

More granular rules for editing items in Ketryx. Currently supports excluding items from being editable based on their type. Therefore, this setting has no effect if "Allow item editing" is set to "No". If it is set to "Yes", however, all items will be editable except for the types excluded using this setting.

Exclude Requirements from Editing

{
  "editItem": {
    "exclude": [
      "Requirement"
    ]
  }
}

Allow item restoring

Whether to allow items to be restored from the Ketryx side (e.g. Risks, Test Executions, other items). By default (if not defined or null), item restoring is allowed based on the project's observe-only flag: In observe-only mode, item restoring is not allowed; otherwise it is allowed.

Enable item approval notifications

Whether to send notifications regarding item approvals. By default (if not defined or null), notifications are sent unless the project is in observe-only mode. Notifications are not sent for required document training.

Enable test case creation in Jira

Configuration for an additional traceability widget button that allows the creation of Xray tests using the Jira dialog. By default, this button is not shown.

Enable legacy traceability widget button with Test issue type mapping

{
  "enableLegacyTraceabilityWidgetButton": true,
  "mapTestCaseToIssueType": {
    "name": "Test"
  }
}

Version number pattern

Pattern for version names, used to extract normalized version number strings.

Warning: Changing the version number pattern in a non-empty project with existing versions and configuration items might change the association of item records with versions, resulting in wide-reaching effects.

SemVer version numbers (major.minor.patch-prerelease+build)

"$0(.$0)(.$0)[-$x][+$x]"

Alphabetical version identifiers (three components, with the second and third one being optional, but being normalized to an empty part)

"$A(.$A)(.$A)"

Select text field options

Option values for each select text field in this project (e.g. region values).

When defining regions, items associated with a specific region will only be shown in region-specific documents, as defined by the document setting Region-specific documents.

Warning: When connected to custom fields in Jira (via the Field names setting), changing this setting will affect the Jira configuration of those custom fields.

Predefine two regions "EU" and "US"

{
  "regions": [
    {
      "value": "EU"
    },
    {
      "value": "US"
    }
  ]
}

Version fields

Configuration for how to determine the start and end version for an item (Introduced in version, Obsolete in version).

This is a mapping from standard item type names (e.g. "Requirement" or "Anomaly") or the wildcard * to a configuration object that lists field keys to consider. The configuration for the wildcard * is used as a fallback, if there is no specific configuration for an item type name.

By default, uses the Ketryx fields Introduced in version and Obsolete in version; in addition, Jira's built-in field Fix version(s) is taken into account (as the end version for Anomalies, or as the start version for all other item types).

Warning: Changing version fields in a non-empty project with existing versions and configuration items might change the association of item records with versions, resulting in wide-reaching effects.

Use an extra custom field "Released Version" as well as Jira's "Fix version(s)" as the introducing version, except for Anomalies where "Fix version(s)" should denote the obsoleting version

{
  "*": {
    "introducedFieldKeys": [
      "extra:Released Version",
      "jira:fixVersions"
    ]
  },
  "Anomaly": {
    "introducedFieldKeys": [
      "extra:Released Version"
    ],
    "obsoleteFieldKeys": [
      "jira:fixVersions"
    ]
  }
}

Incremental releases: Include related items

Whether to include related items in auto-created incremental releases. Disabled by default.

Incremental releases: Excluded from test plan

KQL filter for tests to exclude from the test plan in auto-created incremental releases.

Incremental releases: Omitted documents

Omitted documents in auto-created incremental releases.

Incremental releases: Target branch name

Base ref name (glob pattern) to match against before auto-creating an incremental version. By default, the main analyzed branch is taken.

Incremental releases: Source branch name

Head ref name (glob pattern) to match against before auto-creating an incremental version. By default, all head ref names are accepted.

Create transitive dependency items

Determines whether all direct and indirect dependencies should be created as dependency items. If true, all dependencies, not just root-level ones, need to be acted upon for a release to happen.

Ketryx will scan for vulnerabilities in all dependencies, regardless of this setting as long as the dependencies are found, e.g. in an uploaded SPDX file.

Warning: Be very careful with this setting, as it can lead to a large number of items. Even if this setting is disabled, root-level dependencies will still show their dependencies on their Dependencies tab.

Disabled by default.

Enable threat modeling

Whether to enable the threat modeling feature. Disabled by default.

Note that this feature requires configuration of certain Custom item types.

Threat modeling configuration

Configuration object for the threat modeling feature.

Any value not specifically set here will be used from the default configuration object.

Default configuration object:

{
  "autoAddFields": true,
  "threatRichTextFields": ["Rationale for connecting threats"]
}

Rename threat rich text field

{
  "threatRichTextFields": [
    "Justification for connecting threats"
  ]
}

Hide all rich text fields

{
  "threatRichTextFields": []
}

Add another rich text fields. In this case, the default field must be included in the list.

{
  "threatRichTextFields": [
    "Rationale for connecting threats",
    "Suggested mitigation"
  ]
}

Bypass adding all threat modeling fields to the vulnerability impact assessment form

{
  "autoAddFields": false
}

Enable vulnerability management

Whether to enable the vulnerability management feature. Enabled by default.

Vulnerability management configuration

Configuration object for the vulnerability management feature.

All fields except assessmentHeading and mitigationItemTypes will also affect the Vulnerability Report document. Any value not specifically set here will be used from the default configuration object.

Setting autoAddFields to false will automatically hide the Risks, Mitigations, and Resolution column in the vulnerabilities table on the SBOM > Vulnerabilities page.

Default configuration object

{
  "autoAddFields": true,
  "assessmentHeading": "Vulnerability impact assessment",
  "resolutionLabel": "Resolution",
  "resolutionOptions": [
    "Not relevant",
    "Exploitable",
    "Poses threat"
  ],
  "resolutionRichTextFields": [
    "Justification for resolution"
  ],
  "riskRichTextFields": [
    "Rationale for connecting risks"
  ],
  "mitigationRichTextFields": [
    "Rationale for connecting mitigations"
  ],
  "mitigationItemTypes": [],
  "tableConfiguration": {
    "externalId": false,
    "library": false,
    "originalSeverity": false,
    "kev": false,
    "modifiedDate": false,
    "cisaVulnerabilityName": false,
    "cisaExploitAdd": false,
    "cisaActionDue": false,
    "cisaRequiredAction": false,
    "risks": true,
    "mitigations": true,
    "resolution": true
  }
}

Use a custom assessment heading

{
  "assessmentHeading": "Vulnerability risk analysis"
}

Use a custom resolution configuration

{
  "resolutionLabel": "Overall risk level",
  "resolutionOptions": [
    "None",
    "Low",
    "Medium",
    "High"
  ],
  "resolutionRichTextFields": [
    "Reasoning for risk level"
  ]
}

Rename risk and mitigation rich text fields

{
  "riskRichTextFields": [
    "Reasoning for related risks"
  ],
  "mitigationRichTextFields": [
    "Reasoning for related mitigations"
  ]
}

Hide all rich text fields

{
  "resolutionRichTextFields": [],
  "riskRichTextFields": [],
  "mitigationRichTextFields": []
}

Allow only software item specs and test cases as mitigation items

{
  "mitigationItemTypes": [
    "SOFTWARE_ITEM",
    "TEST_PROTOCOL"
  ]
}

Disable the Risks, Mitigations, and Resolution column

{
  "tableConfiguration": {
    "risks": false,
    "mitigations": false,
    "resolution": false
  }
}

Bypass adding all vulnerability management fields to the vulnerability impact assessment form

{
  "autoAddFields": false
}

Vulnerability scanning configuration

Configuration object for vulnerability scanning.

Allows enabling or disabling specific external vulnerability sources (GHSA, NVD, Build API, project import).

Default configuration

{
  "build": true,
  "buildDeduplication": true,
  "ghsa": true,
  "nvd": false,
  "projectImport": true
}

Use only publicly managed vulnerability databases (GHSA and NVD)

{
  "build": false,
  "buildDeduplication": false,
  "ghsa": true,
  "nvd": true,
  "projectImport": false
}

Manage vulnerabilities only via SBOMs reported through the Build API

{
  "build": true,
  "buildDeduplication": false,
  "ghsa": false,
  "nvd": false,
  "projectImport": false
}

Suggested item type task order

The item type order used by the guidance task system when suggesting a user which first items to create in a new project. Items should be referenced by their standard item type names (e.g. "Requirement") or custom type names (e.g. "Folder").

Have a Requirement, Software Item Spec and Test Case, in that order, suggested by the guidance system

[
  "Requirement",
  "Software Item Spec",
  "Test Case"
]

Have a Requirement (which has renamed to "Functional Requirement" through the "Item type names" configuration field), custom "Folder" item type and a Software Item Spec, in that order, suggested by the guidance system

[
  "Requirement",
  "Folder",
  "Test Case"
]

Webhooks

Webhooks for Ketryx to notify external systems of certain events.

For each of the following events, an object can be specified with properties url (required), method ("POST" or "GET", defaulting to "POST"), and authHeader (optional):

• recordApproval: Approval of an item record

• releaseApproval: Approval of a version/release

• milestoneApproval: Approval of a milestone

• documentApproval: Approval of a document in the EDMS

• testPlanApproval: Approval of a release test plan

• vulnerabilityApproval: Approval of a vulnerability

See also more details in the webhooks API reference.

Send a webhook upon item record approval

{
  "recordApproval": {
    "url": "https://example.com/api/on-record-approval"
  }
}

Send a webhook upon version release approval, using a GET request with a custom Authorization header

{
  "releaseApproval": {
    "url": "https://example.com/api/on-record-approval",
    "method": "GET",
    "authHeader": "Bearer some-secret-token-to-be-sent-along"
  }
}

Custom KQL filters

Using this setting custom KQL filters that should be available on various screens inside Ketryx can be specified.

The following are valid screens:

• AllItems

• Graph

• RiskControl

• RiskManagement

• Tests

• Traceability

If no screens are specified, the query is shown on all screens. Names of queries must be unique.

Add custom KQL queries

[
  {
    "name": "My filter",
    "kqlFilter": "RQ",
    "screens": [
      "ALL_ITEMS",
      "RISK_MANAGEMENT",
      "TRACEABILITY"
    ]
  },
  {
    "name": "My other filter that is shown on all screens",
    "kqlFilter": "SW or HW"
  },
  {
    "name": "Completely hidden filter that is shown on no screens",
    "kqlFilter": "RISK",
    "screens": []
  }
]

New in 2.14

Agent-based filters

You can create filters to find items flagged by specific AI agents. These filters help teams quickly identify items that require attention based on agent analysis.

For example, you can configure a custom filter that filters for items that are part of findings of the Change Request Affected Item Agent:

{
    "name": "Requirement Conflict Detection Filter",
    "kqlFilter": "has-agent-finding-from:\"Change Request Affected Item Agent\"",
}

Related videos

• Agent Filters Introduction

• Agent Filter Setup Demo

CycloneDX field mapping

This setting allows for flexible mapping of data from a CycloneDX Software Bill of Materials (SBOM) to custom fields on Ketryx DEPENDENCY items. The mapping is defined using a set of rules, where each rule specifies how to extract a value from the SBOM and which custom field to populate.

Note: CycloneDX field mapping currently only supports mapping to custom fields, not default fields in Ketryx.

Note: The CycloneDX field mapping advanced setting currently only supports mapping to defined custom fields, not default fields within Ketryx.

Key Concepts:

• JSONPath Expressions (source): Data is extracted from the SBOM using JSONPath expressions. These expressions provide a standardized way to select parts of a JSON document.

• Mapping Contexts:

  • $.component: Use this prefix in your JSONPath expression to query fields within the current CycloneDX component being processed. For example, $.component.name extracts the name of the component.

  • $.doc: Use this prefix to access properties from the root of the CycloneDX document. This is useful for mapping metadata that applies to the entire SBOM, such as $.doc.metadata.timestamp.

• Mapping Rules (mappingRules): This is an array of rule objects. Each rule must have a source (the JSONPath expression) and a target (specifying the customField name).

• Optional Properties:

  • description: A human-readable description of the rule's purpose.

  • appliesToVersion: An array of CycloneDX specification versions (e.g., ["1.5"]) to which the rule should apply. If omitted, the rule applies to all supported versions.

  • enumMapping: A dictionary to translate source values into different target values, which is particularly useful for SELECT type custom fields.

  • defaultValue: A value to be used if the source JSONPath expression does not find a match in the SBOM.

Configuration Structure:

The configuration object has the following main properties:

• mappingSchemaVersion: Must be "1.0.0".

• supportedVersions: An array of CycloneDX specification versions this mapping configuration is designed for (e.g., ["1.4", "1.5"]).

• mappingRules: The array of mapping rules as described above.

Note: Any manual changes made to the values of custom fields that are mapped through this setting will be overwritten the next time a build is reported and a new SBOM is processed.

Map component type to a custom field

{
  "mappingSchemaVersion": "1.0.0",
  "mappingRules": [
    {
      "source": "$.component.type",
      "target": {
        "customField": "Software component type"
      }
    }
  ]
}

Map SBOM generation date to a custom field

{
  "mappingSchemaVersion": "1.0.0",
  "mappingRules": [
    {
      "source": "$.doc.metadata.timestamp",
      "target": {
        "customField": "SBOM generation date"
      }
    }
  ]
}

Map and transform values for a SELECT custom field

{
  "mappingSchemaVersion": "1.0.0",
  "mappingRules": [
    {
      "source": "$.component.type",
      "target": {
        "customField": "Component Category"
      },
      "enumMapping": {
        "library": "Software Library",
        "framework": "Software Framework",
        "application": "Application"
      }
    }
  ]
}

Map multiple values to a MULTI_SELECT custom field

{
  "mappingSchemaVersion": "1.0.0",
  "mappingRules": [
    {
      "source": "$.component.externalReferences[*].type",
      "target": {
        "customField": "Reference Types"
      }
    }
  ]
}

Use a default value if a source field is not present

{
  "mappingSchemaVersion": "1.0.0",
  "mappingRules": [
    {
      "source": "$.component.properties[?(@.name=='Build Number')].value",
      "target": {
        "customField": "Build Number"
      },
      "defaultValue": "N/A"
    }
  ]
}

Handle modified fields across different SBOM specification versions

{
  "mappingSchemaVersion": "1.0.0",
  "supportedVersions": [
    "1.4",
    "1.5",
    "1.6"
  ],
  "mappingRules": [
    {
      "description": "Map from component.author for spec versions < 1.6",
      "appliesToVersion": [
        "1.4",
        "1.5"
      ],
      "source": "$.component.author",
      "target": {
        "customField": "Component Author"
      }
    },
    {
      "description": "Map from component.authors for spec version 1.6",
      "appliesToVersion": [
        "1.6"
      ],
      "source": "$.component.authors[*].name",
      "target": {
        "customField": "Component Author"
      }
    }
  ]
}

Map associated vulnerabilities to a RICH_TEXT custom field

{
  "mappingSchemaVersion": "1.0.0",
  "mappingRules": [
    {
      "source": "$.doc.vulnerabilities[?(@.affects[?(@.ref === @root.component['bom-ref'])])].id",
      "target": {
        "customField": "Associated Vulnerabilities"
      }
    }
  ]
}

Use Ketryx-specific Jira configuration

Determines whether Ketryx should configure the connected Jira space (formerly project) with the Ketryx-specific Jira project configuration for Jira item types, screens, and workflows.

This is only effective if Jira configuration is enabled at the organization level (via the setting Enable Jira configuration).

If this is not specified (neither at the project nor at the organization level), the default is to only use the Ketryx configuration if the space is empty and the project is not in observe-only mode.

Environmental scoring profile

CVSS Environmental scoring profile configuration that defines default environmental metrics for vulnerability scoring.

This setting allows you to define multiple environmental scoring profiles as an array. Each profile must specify a version field and version-specific environmental metrics. Environmental metrics help adjust the base CVSS score based on the specific environment where the vulnerability exists.

Multiple profiles can be defined for each CVSS version, but only the first one will be used.

When environmental metrics are defined, they will be used as defaults when scoring vulnerabilities, allowing for more accurate risk assessment based on your project's specific environment and requirements.

CVSS 3.1 environmental profile with high confidentiality requirement

[
  {
    "version": "3.1",
    "confidentialityRequirement": "H",
    "integrityRequirement": "M",
    "availabilityRequirement": "L"
  }
]

CVSS 4.0 environmental profile with modified attack vector

[
  {
    "version": "4.0",
    "confidentialityRequirement": "H",
    "modifiedAttackVector": "L",
    "modifiedAttackComplexity": "H"
  }
]

Mixed version environmental profiles

[
  {
    "version": "3.1",
    "confidentialityRequirement": "H",
    "integrityRequirement": "H",
    "availabilityRequirement": "M",
    "modifiedAttackVector": "A"
  },
  {
    "version": "4.0",
    "confidentialityRequirement": "H",
    "integrityRequirement": "H",
    "modifiedAttackVector": "N",
    "modifiedAttackComplexity": "L"
  }
]

Integration precedence

Precedence of integrations connected to the project.

This setting determines which connected system sets the properties of synchronized versions. The source of a version which appears first in this list will determine properties of the version.

Default precedence

[
  "Jira",
  "TestRail",
  "Jama",
  "ADO"
]

Enable item rejection

Whether to enable the item rejection feature. Disabled by default.

If enabled, users will be able to reject records whenever they are in an approvable state. A rejection will result in a new record being created in the "Open" state with the same content as the original record.

Require rejection comments

Whether to require comments when users reject records. Disabled by default.

If enabled, users will be required to provide a comment when rejecting records.

Azure DevOps work item mapping

Mapping between Azure DevOps item types and Ketryx items including fields and relationships.

    For each mapped item type, you can specify the following (see examples for each below):

• workItemType: The Azure DevOps item type's key or name (both case-sensitive). To apply a mapping to ALL items, use the wildcard "*".

• itemType: The Ketryx item type used to create items, e.g., REQUIREMENT.

• fields: Mapping of built-in and custom Azure DevOps fields to Ketryx fields (given the field values are compatible). A field mapping can either map field-to-field or field-to-relationship. Such relational fields are especially useful to establish traceability across different systems.

Should a given Azure DevOps item type be mapped multiple times, its mappings will be merged together:

• itemType: The first Ketryx item type will be used.

• fields: All distinct Ketryx/Azure DevOps field keys will be used. In case of conflicts, the first one will be used.

• `"workItemType": "*" is default mapping, i.e., it can be specified only once and will be overridden by more specific item type mappings.

Map one Azure DevOps item type to one Ketryx type

[
  {
    "workItemType": "CR",
    "itemType": "CHANGE_REQUEST"
  }
]

Map Azure DevOps item types using global and type-specific field mappings

[
  {
    "workItemType": "*",
    "fields": {
      "name": "title",
      "description": "description"
    }
  },
  {
    "workItemType": "Risk evaluation",
    "itemType": "RISK",
    "fields": {
      "description": "sequenceOfEvents"
    }
  }
]

Establish traceability between an Azure DevOps project to other source systems

[
  {
    "workItemType": "Software Specification",
    "itemType": "SOFTWARE_ITEM",
    "fields": {
      "Tests Jira item": {
        "type": "references",
        "relationType": "TESTS",
        "targetSystem": "Jira"
      }
    }
  },
  {
    "workItemType": "Risk evaluation",
    "itemType": "RISK",
    "fields": {
      "isControlledBy": {
        "type": "references",
        "relationType": "IS_RISK_CONTROLLED_BY",
        "targetSystem": "Git"
      }
    }
  }
]

Default mapping

[
  {
    "itemType": "REQUIREMENT",
    "workItemType": "Issue",
    "fields": {
      "Title": "title",
      "State": "state",
      "Requirement Type": "requirementType",
      "Description": "description",
      "Steps": "steps",
      "Benefit risk analysis": "riskBenefitAnalysis",
      "Harm": "harm",
      "Hazard": "hazard",
      "Hazardous situation": "hazardousSituation",
      "Hazard type": "hazardTypeText",
      "Probability": "initialOccurrenceProbabilityText",
      "Risk controls description": "riskControlOptions",
      "Sequence of events": "sequenceOfEvents",
      "Introduced in version": "introducedInVersion",
      "Obsolete in version": "obsoleteInVersion"
    }
  },
  {
    "itemType": "REQUIREMENT",
    "workItemType": "Feature",
    "fields": {
      "Title": "title",
      "State": "state",
      "Requirement Type": "requirementType",
      "Description": "description",
      "Steps": "steps",
      "Benefit risk analysis": "riskBenefitAnalysis",
      "Harm": "harm",
      "Hazard": "hazard",
      "Hazardous situation": "hazardousSituation",
      "Hazard type": "hazardTypeText",
      "Probability": "initialOccurrenceProbabilityText",
      "Risk controls description": "riskControlOptions",
      "Sequence of events": "sequenceOfEvents",
      "Introduced in version": "introducedInVersion",
      "Obsolete in version": "obsoleteInVersion"
    }
  },
  {
    "itemType": "REQUIREMENT",
    "workItemType": "Epic",
    "fields": {
      "Title": "title",
      "State": "state",
      "Requirement Type": "requirementType",
      "Description": "description",
      "Steps": "steps",
      "Benefit risk analysis": "riskBenefitAnalysis",
      "Harm": "harm",
      "Hazard": "hazard",
      "Hazardous situation": "hazardousSituation",
      "Hazard type": "hazardTypeText",
      "Probability": "initialOccurrenceProbabilityText",
      "Risk controls description": "riskControlOptions",
      "Sequence of events": "sequenceOfEvents",
      "Introduced in version": "introducedInVersion",
      "Obsolete in version": "obsoleteInVersion"
    }
  },
  {
    "itemType": "TEST_PROTOCOL",
    "workItemType": "Test Case",
    "fields": {
      "Title": "title",
      "State": "state",
      "Requirement Type": "requirementType",
      "Description": "description",
      "Steps": "steps",
      "Benefit risk analysis": "riskBenefitAnalysis",
      "Harm": "harm",
      "Hazard": "hazard",
      "Hazardous situation": "hazardousSituation",
      "Hazard type": "hazardTypeText",
      "Probability": "initialOccurrenceProbabilityText",
      "Risk controls description": "riskControlOptions",
      "Sequence of events": "sequenceOfEvents",
      "Introduced in version": "introducedInVersion",
      "Obsolete in version": "obsoleteInVersion"
    }
  },
  {
    "itemType": "TEST_EXECUTION",
    "workItemType": "Test Execution",
    "fields": {
      "Title": "title",
      "State": "state",
      "Requirement Type": "requirementType",
      "Description": "description",
      "Steps": "steps",
      "Benefit risk analysis": "riskBenefitAnalysis",
      "Harm": "harm",
      "Hazard": "hazard",
      "Hazardous situation": "hazardousSituation",
      "Hazard type": "hazardTypeText",
      "Probability": "initialOccurrenceProbabilityText",
      "Risk controls description": "riskControlOptions",
      "Sequence of events": "sequenceOfEvents",
      "Introduced in version": "introducedInVersion",
      "Obsolete in version": "obsoleteInVersion"
    }
  },
  {
    "itemType": "TEST_PLAN",
    "workItemType": "Test Plan",
    "fields": {
      "Title": "title",
      "State": "state",
      "Requirement Type": "requirementType",
      "Description": "description",
      "Steps": "steps",
      "Benefit risk analysis": "riskBenefitAnalysis",
      "Harm": "harm",
      "Hazard": "hazard",
      "Hazardous situation": "hazardousSituation",
      "Hazard type": "hazardTypeText",
      "Probability": "initialOccurrenceProbabilityText",
      "Risk controls description": "riskControlOptions",
      "Sequence of events": "sequenceOfEvents",
      "Introduced in version": "introducedInVersion",
      "Obsolete in version": "obsoleteInVersion"
    }
  },
  {
    "itemType": "ANOMALY",
    "workItemType": "Bug",
    "fields": {
      "Title": "title",
      "State": "state",
      "Requirement Type": "requirementType",
      "Description": "description",
      "Steps": "steps",
      "Benefit risk analysis": "riskBenefitAnalysis",
      "Harm": "harm",
      "Hazard": "hazard",
      "Hazardous situation": "hazardousSituation",
      "Hazard type": "hazardTypeText",
      "Probability": "initialOccurrenceProbabilityText",
      "Risk controls description": "riskControlOptions",
      "Sequence of events": "sequenceOfEvents",
      "Introduced in version": "introducedInVersion",
      "Obsolete in version": "obsoleteInVersion"
    }
  },
  {
    "itemType": "TASK",
    "workItemType": "Task",
    "fields": {
      "Title": "title",
      "State": "state",
      "Requirement Type": "requirementType",
      "Description": "description",
      "Steps": "steps",
      "Benefit risk analysis": "riskBenefitAnalysis",
      "Harm": "harm",
      "Hazard": "hazard",
      "Hazardous situation": "hazardousSituation",
      "Hazard type": "hazardTypeText",
      "Probability": "initialOccurrenceProbabilityText",
      "Risk controls description": "riskControlOptions",
      "Sequence of events": "sequenceOfEvents",
      "Introduced in version": "introducedInVersion",
      "Obsolete in version": "obsoleteInVersion"
    }
  },
  {
    "itemType": "RISK",
    "workItemType": "Risk",
    "fields": {
      "Title": "title",
      "State": "state",
      "Requirement Type": "requirementType",
      "Description": "description",
      "Steps": "steps",
      "Benefit risk analysis": "riskBenefitAnalysis",
      "Harm": "harm",
      "Hazard": "hazard",
      "Hazardous situation": "hazardousSituation",
      "Hazard type": "hazardTypeText",
      "Probability": "initialOccurrenceProbabilityText",
      "Risk controls description": "riskControlOptions",
      "Sequence of events": "sequenceOfEvents",
      "Introduced in version": "introducedInVersion",
      "Obsolete in version": "obsoleteInVersion"
    }
  },
  {
    "itemType": "REQUIREMENT",
    "workItemType": "Requirement",
    "fields": {
      "Title": "title",
      "State": "state",
      "Requirement Type": "requirementType",
      "Description": "description",
      "Steps": "steps",
      "Benefit risk analysis": "riskBenefitAnalysis",
      "Harm": "harm",
      "Hazard": "hazard",
      "Hazardous situation": "hazardousSituation",
      "Hazard type": "hazardTypeText",
      "Probability": "initialOccurrenceProbabilityText",
      "Risk controls description": "riskControlOptions",
      "Sequence of events": "sequenceOfEvents",
      "Introduced in version": "introducedInVersion",
      "Obsolete in version": "obsoleteInVersion"
    }
  }
]

Azure DevOps status mapping

Defines a mapping between Azure DevOps status labels and Ketryx item states (OPEN, REOPENED, IN_PROGRESS, RESOLVED, or CLOSED). This configuration ensures seamless synchronization of work item statuses across systems by translating ADO-specific statuses to their corresponding Ketryx states.

Map ADO statuses "Proposed" and "Design" to Ketryx state Open, and "Completed" to Closed

{
  "Proposed": "OPEN",
  "Design": "OPEN",
  "Completed": "CLOSED"
}

Default mapping

{
  "Proposed": "OPEN",
  "Design": "OPEN",
  "Planning": "OPEN",
  "Active": "RESOLVED",
  "In Progress": "IN_PROGRESS",
  "Ready": "RESOLVED",
  "Resolved": "RESOLVED",
  "Closed": "CLOSED",
  "Completed": "CLOSED",
  "Inactive": "CLOSED"
}

Azure DevOps work item relations mapping

Defines how Azure DevOps work item relationships are mapped to corresponding Ketryx relationship types. This configuration enables consistent handling of linked items, such as parent-child relationships, test dependencies, or other custom relations, across both systems.

Mappings are defined as key-value pairs where the key represents the Azure DevOps relation type (e.g., 'Parent' or 'Tested By') and the value specifies the equivalent Ketryx relation type (e.g., 'HAS_PARENT' or 'TESTS').

Map Test items

{
  "Tested By": "TESTS"
}

Map Parent items

{
  "Parent": "HAS_PARENT"
}

Default mapping

{
  "Microsoft.VSTS.Common.Affects-Forward": "AFFECTS",
  "System.LinkTypes.Hierarchy-Forward": "HAS_PARENT",
  "System.LinkTypes.Related": "RELATES_TO",
  "Microsoft.VSTS.Common.TestedBy-Forward": "TESTS"
}

TestRail sync configuration

Configuration for TestRail synchronization behavior.

The configuration consists of:

• syncFilter: Controls which items are included in the sync

  • milestonePattern: Regular expression pattern to match milestone names

    • '.*' matches all milestones

    • 'v\d+.\d+' matches version milestones (e.g., 'v1.0', 'v2.1')

    • 'release-.*' matches all release milestones

    • 'sprint-\d+' matches sprint milestones (e.g., 'sprint-1', 'sprint-2')

  • baselinePattern: Regular expression pattern to match baseline/suite names

    • '.*' matches all baselines

    • 'master' matches only master baseline

    • 'baseline-\d+' matches numbered baselines (e.g., 'baseline-1', 'baseline-2')

    • 'regression-.*' matches all regression baselines

• syncOptions: Controls sync behavior

  • includeMasterBaseline: Whether to include the master baseline in the sync

    • true: Master baselines are included (default)

    • false: Master baselines are skipped

  • includeCompletedItems: Controls how completed items are handled

    • milestones: Whether to include completed milestones

      • true: Completed milestones are included (default)

      • false: Completed milestones are skipped

    • baselines: Whether to include completed baselines

      • true: Completed baselines are included (default)

      • false: Completed baselines are skipped

    • runs: Whether to include completed test runs

      • true: Completed test runs are included (default)

      • false: Completed test runs are skipped

    • plans: Whether to include completed test plans

      • true: Completed test plans are included (default)

      • false: Completed test plans are skipped

• syncScope: Controls the overall sync scope

  • 'All': Syncs all items regardless of milestone association (default)

  • 'Milestone': Only syncs items associated with milestones that match the milestonePattern

Default configuration

{
  "syncFilter": {
    "milestonePattern": ".*",
    "baselinePattern": ".*"
  },
  "syncOptions": {
    "includeMasterBaseline": true,
    "includeCompletedItems": {
      "milestones": true,
      "baselines": true,
      "runs": true,
      "plans": true
    }
  },
  "syncScope": "All"
}

Version-specific configuration

{
  "syncFilter": {
    "milestonePattern": "v\\d+\\.\\d+",
    "baselinePattern": "master"
  },
  "syncOptions": {
    "includeMasterBaseline": true,
    "includeCompletedItems": {
      "milestones": false,
      "baselines": false,
      "runs": false,
      "plans": false
    }
  },
  "syncScope": "Milestone"
}

TestRail field type mapping

Mapping between different TestRail-specific fields and Ketryx. This mapping is essential for translating fields used in TestRail into their corresponding representations in Ketryx.

The following types are supported:

• TEST_PROTOCOL: Mappings for test cases, including defaults and client-specific templates

• TEST_EXECUTION: Mappings for executing tests

• TEST_PLAN: Mappings for planning tests

Map Custom Fields

{
  "TEST_PROTOCOL": {
    "DEFAULT": {
      "refs": "refs",
      "description": "custom_description",
      "introducedInVersion": "custom_prd_ver",
      "steps": "custom_steps_separated",
      "expectedBehavior": "custom_expected"
    },
    "My Custom Template": {
      "refs": "refs",
      "description": "custom_description_for_steps",
      "introducedInVersion": "custom_version",
      "steps": "custom_steps",
      "expectedBehavior": "custom_expected_behavior"
    }
  },
  "TEST_EXECUTION": {
    "description": "custom_execution_desc",
    "introducedInVersion": "custom_exec_prd_ver",
    "steps": "custom_step_results",
    "expectedBehavior": "custom_expected_exec"
  },
  "TEST_PLAN": {
    "refs": "refs",
    "description": "custom_plan_desc"
  }
}

TestRail status mapping

Mapping from TestRail status names to Ketryx item states (OPEN, REOPENED, IN_PROGRESS, RESOLVED, or CLOSED).

Map the status "Backlog" to the Ketryx state Open, and "Done" to Resolved

{
  "Backlog": "OPEN",
  "Done": "RESOLVED"
}

TestRail result mapping

Mapping from TestRail result names to Ketryx item states (PASSED, FAILED, FAIL_ACCEPTED or PASS_WITH_EXCEPTION).

Map the result "Passed" to the Ketryx state Passed

{
  "passed": "PASS",
  "failed": "FAIL"
}

TestRail work item relations mapping

Mapping between TestRail-specific fields and Ketryx relations. Source field is the field in TestRail, relationType is the relation in Ketryx and targetSystem is the system where the target item is located. targetSystem can be ('Jira', 'ADO', 'TestRail', 'Git').

Map custom field to map as item affects from jira item

[
  {
    "sourceField": "my_custom_field",
    "relationType": "AFFECTS",
    "targetSystem": "Jira"
  }
]

Jama item mapping

Mapping between Jama item types and Ketryx items including fields and relationships.

For each mapped item type, you can specify the following (see examples for each below):

• jamaItemType: The Jama item type's key or name (both case-sensitive). To apply the same mapping to multiple types, use an array of keys/names; to apply a mapping to ALL items, use the wildcard "*".

• jamaItemCategory: Anomalies and test cases can also be mapped by the corresponding Jama item type category (Use as); supported categories are DEFECT, TEST_CASE, TEST_PLAN, TEST_RUN.

• itemType: The Ketryx item type used to create items, e.g., REQUIREMENT.

• fieldValues: Static fields that only depend on the item type and are not read from the Jama item.

• fields: Mapping of built-in and custom Jama fields to Ketryx fields (given the field values are compatible). A field mapping can either map field-to-field or field-to-relationship. Such relational fields are especially useful to establish traceability across different systems or across Ketryx projects. If no targetSystem is specified, it defaults to KETRYX.

• relationships: Mapping of built-in and custom Jama relationship types to Ketryx relationships. For Jama-to-non-Jama relationships, use the object-syntax and specify a target system.

Should a given Jama item type be mapped multiple times, its mappings will be merged together:

• itemType: The first Ketryx item type will be used.

• fieldValues and fields: All distinct Ketryx/Jama field keys will be used. In case of conflicts, the first one will be used.

• "jamaItemType": "*" and jamaItemCategory are default mappings, i.e., they can specified only once and will be overridden by more specific item type mappings.

Map one or many Jama item types to one Ketryx type

[
  {
    "jamaItemType": "CR",
    "itemType": "CHANGE_REQUEST"
  },
  {
    "jamaItemType": [
      "RISK",
      "HRM",
      "HAZ"
    ],
    "itemType": "RISK"
  }
]

Map a Jama item type category to a Ketryx type

[
  {
    "jamaItemCategory": "DEFECT",
    "itemType": "ANOMALY"
  }
]

Map Jama item types with static field values

[
  {
    "jamaItemType": "Use Case",
    "itemType": "REQUIREMENT",
    "fieldValues": {
      "requirementType": {
        "value": "Use case"
      }
    }
  }
]

Map Jama item types using global and type-specific field mappings

[
  {
    "jamaItemType": "*",
    "fields": {
      "name": "title",
      "description": "description"
    }
  },
  {
    "jamaItemType": "Risk evaluation",
    "itemType": "RISK",
    "fields": {
      "description": "sequenceOfEvents",
      "severity": {
        "type": "mapToMany",
        "toFields": [
          "initialSeverity",
          "residualSeverity"
        ]
      }
    }
  }
]

Establish traceability across multiple Jama projects and to other source systems

[
  {
    "jamaItemType": "Software Specification",
    "itemType": "SOFTWARE_ITEM",
    "relationships": {
      "Fulfills": "FULFILLS",
      "Related to": {
        "relationType": "IS_RELATED_TO",
        "targetSystem": "Jira"
      }
    }
  },
  {
    "jamaItemType": "Risk evaluation",
    "itemType": "RISK",
    "fields": {
      "isControlledBy": {
        "type": "references",
        "relationType": "IS_RISK_CONTROLLED_BY",
        "targetSystem": "Jira"
      }
    }
  }
]

Map inverse Jama relationships

[
  {
    "jamaItemType": "Requirement",
    "itemType": "REQUIREMENT",
    "fields": {
      "introducesTest": {
        "relationType": "TESTS",
        "targetSystem": "Jama",
        "isUpstream": true
      }
    },
    "relationships": {
      "Fulfilled by": {
        "relationType": "FULFILLS",
        "targetSystem": "Jama",
        "isUpstream": true
      }
    }
  }
]

Disable default mappings

Either disable the entire item type, or specific fields and relationships. For a disabled item type, no new records are created. To remove existing items from Ketryx, they may be excluded on the All items page.

[
  {
    "jamaItemType": "VER",
    "itemType": null
  },
  {
    "jamaItemType": "RQ",
    "itemType": "REQUIREMENT",
    "fields": {
      "description": null
    },
    "relationships": {
      "Related to": null
    }
  }
]

Jama item status mapping

Mapping from Jama status names to Ketryx states.

Map Jama status names

{
  "To Do": "OPEN"
}

Jama item relationships mapping

Mapping from Jama item relationships to Ketryx relations.

Map Jama item relationships

{
  "Related to": "RELATES_TO"
}

Jama field type mapping

Mapping from Jama-specific fields to Ketryx fields.

Note: This is deprecated, please use Jama item mapping instead.

For releases, please be aware that Jama and Ketryx assign items differently. For the best experience, we recommend using two custom release fields.

Optionally, specify a relation from a field to establish traceability to other source systems like Jira.

Map item fields

{
  "status": "statusName",
  "assignedTo": "assignee",
  "release1": "introducedInVersion",
  "release2": "obsoleteInVersion"
}

Jama relations field mapping

Combination of field- and relation mapping to link items based on a field instead of a relationship, e.g., to establish traceability across source systems.

Note: This is deprecated, please use Jama item mapping instead.

The sourceField is the field in Jama and expected to hold the target item's Ketryx ID or the key by which the source system uniquely identifies the item, e.g., for Jira this would be the Jira issue key. relationType is the relation in Ketryx and targetSystem is the system where the target item is located (Ketryx by default). targetSystem can be one of ADO, Confluence, Git, Jama, Jira, Ketryx, Polarion, TestRail.

Use a field to link to other items, including from other source systems

[
  {
    "sourceField": "myCustomField",
    "relationType": "AFFECTS",
    "targetSystem": "Jira"
  }
]

Jama releases

Configure how releases are handled in Jama. The default (no configuration) is to use Jama's built-in releases and corresponding fields (use field type mapping to associate items with these releases).

An alternative mode available through this setting is to use multi-select fields as source for releases. Based on these Jama fields, Ketryx knows which picklists to interpret as Ketryx versions and will then associate corresponding items to each selected version.

Use custom multi-select picklists instead of Jama releases

{
  "picklist": {
    "pinnedVersionFields": [
      "customReleaseField"
    ]
  }
}

Document configuration

Omitted documents

Omitted document types in this project. These documents will not show up on a version's documents page and will not be required for approving a version.

This is separate from omitting documents "ad-hoc" on a version's Documents page, which only affects that particular version.

If not defined, a default set of omitted documents will be chosen based on the chosen schema configuration mode of the project.

Use all available documents

[]

Omit all documents except for the SRS document

[
  "AUTHORITY_MATRIX",
  "CHANGE_REQUEST_REPORT",
  "CHANGE_MANAGEMENT_FILE",
  "CLOUD_CONFIG_REPORT",
  "CODE_REVIEW_REPORT",
  "CYBER_RISK_MANAGEMENT_FILE",
  "PROBLEM_REPORT",
  "RELEASE_NOTES",
  "RISK_MANAGEMENT_FILE",
  "RISK_CONTROL_FILE",
  "RISK_MATRIX",
  "SOFTWARE_ARCHITECTURE_CHART",
  "SOFTWARE_DESIGN_SPECIFICATION",
  "SOFTWARE_DESIGN_STRUCTURE_MATRIX",
  "SOUP_DEPENDENCIES",
  "TRAINING_STATUS_REPORT",
  "TEST_PLAN",
  "TESTING_REPORT",
  "TRACEABILITY_MATRIX",
  "UNRESOLVED_ANOMALIES",
  "VULNERABILITY_REPORT"
]

Region-specific documents

Documents that should be generated for each region. Possible region values are defined in Select text field options.

By default, only the SRS document is considered region-specific.

Generate SRS and SDS document for each region

[
  "SOFTWARE_REQUIREMENTS_SPECIFICATION",
  "SOFTWARE_DESIGN_SPECIFICATION"
]

Require up-to-date milestone documents

Whether milestone documents are required to be up-to-date for the milestone to be approvable. Enabled by default.

Show outdated state for milestone/release documents

Whether milestone and release documents display an "Outdated" state on the UI when Ketryx determines that they do not contain the latest information. This setting is enabled by default.

NOTE: Disabling this will only affect release documents if the "Require up-to-date release documents" release control is disabled. Similarly, it will only affect milestone documents if the "Require up-to-date milestone documents" advanced setting is disabled.

Milestone-independent documents

Documents that should contain all items (independently of milestones), even if they are generated as milestone documents.

Default list of documents that are considered milestone-independent

[
  "CYBER_RISK_MANAGEMENT_FILE",
  "PROBLEM_REPORT",
  "RELEASE_NOTES",
  "TEST_PLAN",
  "TESTING_REPORT",
  "UNRESOLVED_ANOMALIES"
]

Require controlled templates

Whether to only use document templates that are in a controlled state (off by default). If activated, any unapproved draft will be ignored, and the last controlled record of a template will continue to be used instead.

• Recommendation: We recommend setting this to 'yes' once you are satisfied with the current version of your templates and want to approve them (and maintain approvals).

• *Note: When this setting is active, uploading a revision of an approved template will not make it immediately available for creating new documents. The new version must first complete the required approval workflow before it replaces the previous controlled version on the Release Documents screen.

Omitted fields

Omitted fields for each document type and item type. Word documents showing the details of an item will not show those omitted fields.

Document types and item types are denoted by their internal identifiers. Fields are denoted by their human-readable name (e.g. "Description", "My custom field").

Omit the "Expected behavior" field from Test Cases in the Test Plan documents

{
  "TEST_PLAN": {
    "TEST_PROTOCOL": [
      "Expected behavior"
    ]
  }
}

Include title page

Whether to include a title page (on by default).

Include version page

Whether to include a page listing the document version history (on by default).

Word document

Settings for all generated Word documents.

Use the setting for Custom template variables to define custom template variables such as $DOC_ID.

Footer

{
  "footer": {
    "content": [
      {
        "left": {
          "text": "Electronically controlled document by My Corporation",
          "style": {
            "size": 8,
            "fontName": "Tahoma"
          }
        },
        "middle": {
          "text": "Confidential",
          "style": {
            "bold": true,
            "size": 10,
            "italics": true,
            "fontName": "Tahoma"
          }
        },
        "right": {
          "text": "Document ID $DOC_ID",
          "style": {
            "size": 8,
            "fontName": "Tahoma"
          }
        }
      }
    ],
    "borderTop": {
      "size": 10,
      "color": "333333",
      "style": "thick"
    }
  }
}

Excel spreadsheet

Settings for all generated Excel spreadsheets.

Custom template variables

Allows customizing the template variable input for all document types. A template variable may be configured to be user-adjustable, which would show extra inputs in the release documents UI.

This is usually used in combination with custom headers and footers.

Introduce a user-adjustable $DOC_ID variable

{
  "$DOC_ID": {
    "value": "",
    "description": "Document ID",
    "userAdjustable": true
  }
}

System Requirements Specification

Customization of SRS output documents.

Omit a dedicated "Other" section heading if it is the only section in the document

{
  "omitSingleOtherSection": true
}

Requirements Traceability Matrix

Customization of RTM output documents.

Omit use cases and specs from the RTM document

{
  "showUseCases": false,
  "showSpecs": false
}

Do not show excluded tests at all

{
  "showExcludedTests": "never"
}

Do not show excluded tests if there is no "inherited" test in the previous release

{
  "showExcludedTests": "if-inherited-execution"
}

Rename the use-case-related columns, and omit the "Requirement type" column

{
  "columnNames": {
    "Use case ID": "User requirement ID",
    "Use case title": "User requirement title",
    "Requirement type": null
  }
}

Add an additional traceability matrix to support document templating of Anomalies and CAPAs

{
  "extraConfigurations": {
    "ANConfig": {
      "columns": [
        {
          "columnId": "anomaly",
          "itemFilter": "type:AN",
          "kind": "design",
          "relations": [
            {
              "kind": "indirect",
              "referencedColumnId": "capa",
              "relationType": "RESOLVED_BY"
            }
          ],
          "title": "Anomaly"
        },
        {
          "columnId": "capa",
          "itemFilter": "type:CAPA",
          "kind": "design",
          "title": "Capa"
        }
      ],
      "defaultColumnId": "anomaly",
      "rtmApprovalEnabled": false,
      "version": "3"
    }
  }
}

Risk Matrix

Customization of Risk Matrix output documents.

Rename some columns, and omit the "System categories" column

{
  "columnNames": {
    "Item ID": "ID",
    "System categories": null,
    "Foreseeable sequence of events": "Sequence of events"
  }
}

Release history

Customization of Release History documents.

Default values:

{
  "includeScopeDescriptionSection": true,
  "omitVVReportSection": true
}

Remove the Scope description section from the release history document

{
  "includeScopeDescriptionSection": false
}

Include the V&V section in the release history document

{
  "omitVVReportSection": false
}

Release Notes

Customization of Release Notes documents.

Default values:

{
  "includeScopeDescriptionSection": true,
  "omitVVReportSection": true
}

Remove the Scope description section from the release notes

{
  "includeScopeDescriptionSection": false
}

Include the V&V section in the release notes

{
  "omitVVReportSection": false
}

Only include certain user requirements in the release notes

{
  "itemFilters": {
    "newRequirements": "\"Requirement type\":(\"User/Marketing\", \"Intended use\")",
    "changedRequirements": "\"Requirement type\":(\"User/Marketing\", \"Intended use\")",
    "removedRequirements": "\"Requirement type\":(\"User/Marketing\", \"Intended use\")"
  }
}

Only include corrective anomalies in the release notes

{
  "itemFilters": {
    "newUnresolvedAnomalies": "\"Problem report type\":Corrective",
    "resolvedAnomalies": "\"Problem report type\":Corrective"
  }
}

SBoM – SOUP – Software Configuration report

Customization of SBoM – SOUP – Software Configuration Report documents.

Rename the column "Dependency name" to "Name"

{
  "columnNames": {
    "Dependency name": "Name"
  }
}

Omit the "Ecosystem" column

{
  "columnNames": {
    "Ecosystem": null
  }
}

Test Plan

Customization of Test Plan documents.

Omit automated tests from the Test Plan Word document

{
  "showAutomatedTests": false
}

Testing Report

Customization of Testing Report documents.

Only show the last (effective) test execution for each test in the Testing Report Word document

{
  "onlyLastTestExecution": true
}

Risk Management File

Customization of Risk Management File documents.

Omit the risk evaluation matrix section from the document

{
  "showEvaluationMatrices": false
}

Omit the general information section from the document

{
  "showGeneralInformation": false
}

Date format

Default date format to render date/time values in template-based documents. Placeholders as defined by Unicode TR35 can be used.

ISO 6801-compliant time stamps

"yyyy-MM-dd'T'HH:mm:ssXXX"

Date time zone

Default time zone to use for date/time values in template-based documents. Time zones are specified using their TZ identifier.

Use the New York time zone

"America/New_York"

Normalization

Document normalization settings.

Enable embedding of EDMS documents

Whether to enable embedding of EDMS documents. The Assistant uses these embeddings when answering user queries about their documents. If enabled, EDMS documents are sent to a zero data retention service for processing.

Test result names

Mapping of internal test result status names to custom ones.

As a special value, "EXCLUDED" can also be mapped to a custom value (with the default label being "Excluded" in the RTM).

Use custom test result names

{
  "PASS": "Passed",
  "PASS_WITH_EXCEPTION": "Passed with exception",
  "FAIL_ACCEPTED": "Failed but accepted",
  "FAIL": "Failed",
  "EXCLUDED": "Excluded"
}

Short item refs

Use short item references (usually just the Jira issue key) instead of long references (that also indicate the item type and revision number). Defaults to false if not defined.

Edit release documents externally

Use external editors to collaborate on release documents. This requires a connection for the respective system.

Google Docs

{
  "googleDocs": {
    "folderId": "1AB0VbQpyD0pHpBQAbRaptfNDsVTbgXfaF"
  }
}

Risk configuration

Hazardous situations

Customization of hazardous situation values.

Set new hazardous situation values

[
  "Patient harm",
  "Inaccurate readings",
  "Communication failure"
]

Event sequences

Customization of event sequence values.

Set a new event sequence value

[
  {
    "name": "Medication Dosage Error Risk",
    "steps": [
      {
        "name": "Prescription Entry"
      },
      {
        "name": "Dosage Calculation"
      },
      {
        "name": "Dispensing Medication"
      },
      {
        "name": "Administering Medication"
      }
    ]
  }
]

Event steps

Customization of event step values.

Set new event step values

[
  {
    "name": "Prescription Entry"
  },
  {
    "name": "Patient Identification"
  },
  {
    "name": "Medication Verification"
  }
]

Hazards

Customization of hazard values.

Set new hazard values

[
  "Contamination",
  "Overdose",
  "Burns"
]

Harms

Customization of harm values. A harm may include an associated initial severity. If strict mode is enabled, it is recommended to add the severity.

Set new harm values

[
  {
    "name": "Organ Damage",
    "defaultInitialSeverity": "High"
  },
  {
    "name": "Infection"
  }
]

Hazard types

Customization of hazard type values.

Warning: If the Hazard type field is mapped to a custom field in Jira (via Field names), changing this setting will result in a global configuration change of that custom field.

Set new hazard type values

[
  "Acoustic",
  "Electrical",
  "Mechanical"
]

System categories

Customization of system category values.

Warning: If the System categories field is mapped to a custom field in Jira (via Field names), changing this setting will result in a global configuration change of that custom field.

Set new system category values

[
  "Environment",
  "Mechanical",
  "Software"
]

Risk assessment methodologies

Customization of risk assessment methodology values.

Warning: If the Risk assessment methodologies field is mapped to a custom field in Jira (via Field names), changing this setting will result in a global configuration change of that custom field.

Set new risk assessment methodology values

[
  "FMEA",
  "FTA"
]

Initial harm probability

Customization of initial harm probability values.

Providing the font color is optional and should be used to provide contrast to the background color hexColor. By default, the font color is white.

Warning: If the Initial harm probability field is mapped to a custom field in Jira (via Field names), changing this setting will result in a global configuration change of that custom field.

Set new harm probability values

[
  {
    "name": "Low",
    "hexColor": "39A31A",
    "fontHexColor": "EBFFE4"
  },
  {
    "name": "Medium",
    "hexColor": "D08300",
    "fontHexColor": "FFF7E4"
  },
  {
    "name": "High",
    "hexColor": "B50531",
    "fontHexColor": "FFEDF3"
  }
]

Initial occurrence probability

Customization of initial occurrence probability values.

Providing the font color is optional and should be used to provide contrast to the background color hexColor. By default, the font color is white.

Warning: If the Initial occurrence probability field is mapped to a custom field in Jira (via Field names), changing this setting will result in a global configuration change of that custom field.

Set new occurrence probability values

[
  {
    "name": "Low",
    "hexColor": "39A31A",
    "fontHexColor": "EBFFE4"
  },
  {
    "name": "Medium",
    "hexColor": "D08300",
    "fontHexColor": "FFF7E4"
  },
  {
    "name": "High",
    "hexColor": "B50531",
    "fontHexColor": "FFEDF3"
  }
]

Initial total probability

Customization of initial total probability values.

Providing the font color is optional and should be used to provide contrast to the background color hexColor. By default, the font color is white.

Warning: If the Initial total probability field is mapped to a custom field in Jira (via Field names), changing this setting will result in a global configuration change of that custom field.

Set new total probability values

[
  {
    "name": "Rare",
    "hexColor": "39A31A",
    "fontHexColor": "EBFFE4"
  },
  {
    "name": "Probable",
    "hexColor": "D08300",
    "fontHexColor": "FFF7E4"
  },
  {
    "name": "Certain",
    "hexColor": "B50531",
    "fontHexColor": "FFEDF3"
  }
]

Initial severity

Customization of initial severity values.

Providing the font color is optional and should be used to provide contrast to the background color hexColor. By default, the font color is white.

Warning: If the Initial severity field is mapped to a custom field in Jira (via Field names), changing this setting will result in a global configuration change of that custom field.

Set new severity values

[
  {
    "name": "Low",
    "hexColor": "39A31A",
    "fontHexColor": "EBFFE4"
  },
  {
    "name": "Medium",
    "hexColor": "D08300",
    "fontHexColor": "FFF7E4"
  },
  {
    "name": "High",
    "hexColor": "B50531",
    "fontHexColor": "FFEDF3"
  }
]

Initial risk acceptability evaluation

Customization of initial risk acceptability evaluation values.

Providing the font color is optional and should be used to provide contrast to the background color hexColor. By default, the font color is white.

Warning: If the Initial risk evaluation field is mapped to a custom field in Jira (via Field names), changing this setting will result in a global configuration change of that custom field.

Set new risk evaluation values

[
  {
    "name": "Minor",
    "hexColor": "39A31A",
    "fontHexColor": "EBFFE4",
    "acceptable": "ACCEPTABLE"
  },
  {
    "name": "Moderate",
    "hexColor": "D08300",
    "fontHexColor": "FFF7E4",
    "acceptable": "NOT_ACCEPTABLE"
  },
  {
    "name": "Major",
    "hexColor": "B50531",
    "fontHexColor": "FFEDF3",
    "acceptable": "NOT_ACCEPTABLE"
  }
]

Residual harm probability

Customization of residual harm probability values.

Providing the font color is optional and should be used to provide contrast to the background color hexColor. By default, the font color is white.

Warning: If the Residual harm probability field is mapped to a custom field in Jira (via Field names), changing this setting will result in a global configuration change of that custom field.

Set new harm probability values

[
  {
    "name": "Low",
    "hexColor": "39A31A",
    "fontHexColor": "EBFFE4"
  },
  {
    "name": "Medium",
    "hexColor": "D08300",
    "fontHexColor": "FFF7E4"
  },
  {
    "name": "High",
    "hexColor": "B50531",
    "fontHexColor": "FFEDF3"
  }
]

Residual occurrence probability

Customization of residual occurrence probability values.

Providing the font color is optional and should be used to provide contrast to the background color hexColor. By default, the font color is white.

Warning: If the Residual occurrence probability field is mapped to a custom field in Jira (via Field names), changing this setting will result in a global configuration change of that custom field.

Set new occurrence probability values

[
  {
    "name": "Low",
    "hexColor": "39A31A",
    "fontHexColor": "EBFFE4"
  },
  {
    "name": "Medium",
    "hexColor": "D08300",
    "fontHexColor": "FFF7E4"
  },
  {
    "name": "High",
    "hexColor": "B50531",
    "fontHexColor": "FFEDF3"
  }
]

Residual severity

Customization of residual severity values.

Providing the font color is optional and should be used to provide contrast to the background color hexColor. By default, the font color is white.

Warning: If the Residual severity field is mapped to a custom field in Jira (via Field names), changing this setting will result in a global configuration change of that custom field.

Set new severity values

[
  {
    "name": "Low",
    "hexColor": "39A31A",
    "fontHexColor": "EBFFE4"
  },
  {
    "name": "Medium",
    "hexColor": "D08300",
    "fontHexColor": "FFF7E4"
  },
  {
    "name": "High",
    "hexColor": "B50531",
    "fontHexColor": "FFEDF3"
  }
]

Residual total probability

Customization of residual total probability values.

Providing the font color is optional and should be used to provide contrast to the background color hexColor. By default, the font color is white.

Warning: If the Residual total probability field is mapped to a custom field in Jira (via Field names), changing this setting will result in a global configuration change of that custom field.

Set new total probability values

[
  {
    "name": "Rare",
    "hexColor": "39A31A",
    "fontHexColor": "EBFFE4"
  },
  {
    "name": "Probable",
    "hexColor": "D08300",
    "fontHexColor": "FFF7E4"
  },
  {
    "name": "Certain",
    "hexColor": "B50531",
    "fontHexColor": "FFEDF3"
  }
]

Residual risk acceptability evaluation

Customization of residual risk acceptability evaluation values.

Providing the font color is optional and should be used to provide contrast to the background color hexColor. By default, the font color is white.

Warning: If the Residual risk evaluation field is mapped to a custom field in Jira (via Field names), changing this setting will result in a global configuration change of that custom field.

Set new risk evaluation values

[
  {
    "name": "Minor",
    "hexColor": "39A31A",
    "fontHexColor": "EBFFE4",
    "acceptable": "ACCEPTABLE"
  },
  {
    "name": "Moderate",
    "hexColor": "D08300",
    "fontHexColor": "FFF7E4",
    "acceptable": "NOT_ACCEPTABLE"
  },
  {
    "name": "Major",
    "hexColor": "B50531",
    "fontHexColor": "FFEDF3",
    "acceptable": "NOT_ACCEPTABLE"
  }
]

Initial total probability matrix

Customization of the initial total probability matrix.

The utilized keys and values in the JSON object must correspond to actual values in the Initial harm probability, Initial occurrence probability and Initial total probability configurations.

The configuration takes on the following structure:

{
  "[Occurrence probability value]": {
    "[Harm probability value]": "[Total probability value]"
  }
}

The matrix should cover all possible combinations. Doing otherwise will lead to unexpected behavior by the system.

Set new matrix values

{
  "Low": {
    "Low": "Rare",
    "Medium": "Rare",
    "High": "Rare"
  },
  "Medium": {
    "Low": "Rare",
    "Medium": "Probable",
    "High": "Probable"
  },
  "High": {
    "Low": "Rare",
    "Medium": "Probable",
    "High": "Certain"
  }
}

Initial risk evaluation matrix

Customization of the initial risk evaluation matrix.

The utilized keys and values in the JSON object must correspond to actual values in the Initial risk evaluation, Initial severity and Initial total probability configurations.

The configuration takes on the following structure:

{
  "[Total probability value]": {
    "[Severity value]": "[Risk evaluation value]",
  }
}

The matrix should cover all possible combinations. Doing otherwise will lead to unexpected behavior by the system.

Set new matrix values

{
  "Rare": {
    "Low": "Minor",
    "Medium": "Minor",
    "High": "Moderate"
  },
  "Probable": {
    "Low": "Minor",
    "Medium": "Moderate",
    "High": "Major"
  },
  "Certain": {
    "Low": "Minor",
    "Medium": "Moderate",
    "High": "Major"
  }
}

Residual total probability matrix

Customization of the residual total probability matrix.

The utilized keys and values in the JSON object must correspond to actual values in the Residual harm probability, Residual occurrence probability and Residual total probability configurations.

The configuration takes on the following structure:

{
  "[Occurrence probability value]": {
    "[Harm probability value]": "[Total probability value]",
  }
}

The matrix should cover all possible combinations. Doing otherwise will lead to unexpected behavior by the system.

Set new matrix values

{
  "Low": {
    "Low": "Rare",
    "Medium": "Rare",
    "High": "Rare"
  },
  "Medium": {
    "Low": "Rare",
    "Medium": "Probable",
    "High": "Probable"
  },
  "High": {
    "Low": "Rare",
    "Medium": "Probable",
    "High": "Certain"
  }
}

Residual risk evaluation matrix

Customization of the residual risk evaluation matrix.

The utilized keys and values in the JSON object must correspond to actual values in the Residual risk evaluation, Residual severity and Residual total probability configurations.

The configuration takes on the following structure:

{
  "[Total probability value]": {
    "[Severity value]": "[Risk evaluation value]",
  }
}

The matrix should cover all possible combinations. Doing otherwise will lead to unexpected behavior by the system.

Set new matrix values

{
  "Rare": {
    "Low": "Minor",
    "Medium": "Minor",
    "High": "Moderate"
  },
  "Probable": {
    "Low": "Minor",
    "Medium": "Moderate",
    "High": "Major"
  },
  "Certain": {
    "Low": "Minor",
    "Medium": "Moderate",
    "High": "Major"
  }
}

Hazard type-specific configuration

Customization of hazard type-specific configuration.

The configuration takes on the following structure:

{
  "[Hazard type value]": {
    "initialTotalProbabilityMatrix": {...},
    "initialRiskEvaluationMatrix": {...},
    "residualTotalProbabilityMatrix": {...},
    "residualRiskEvaluationMatrix": {...},
  }
}

Details on how to define each matrix can be found by inspecting the relevant field in the advanced settings page.

Set Acoustic hazard type-specific initial total probability matrix

{
  "Acoustic": {
    "initialRiskEvaluationMatrix": {
      "Rare": {
        "Low": "Major",
        "High": "Major",
        "Medium": "Major"
      },
      "Certain": {
        "Low": "Minor",
        "High": "Major",
        "Medium": "Moderate"
      },
      "Probable": {
        "Low": "Minor",
        "High": "Major",
        "Medium": "Moderate"
      }
    }
  }
}

Custom risk type based risk configuration

Customization of custom risk type based configuration. This configuration is useful for managing multiple types of risks with different risk evaluation schemas.

The configuration takes on the following structure:

{
  "[Risk type name]": {
    "initialTotalProbabilityMatrix": {...},
    "initialRiskEvaluationMatrix": {...},

    "residualTotalProbabilityMatrix": {...},
    "residualRiskEvaluationMatrix": {...},

    "initialHarmProbability": [...],
    "initialOccurrenceProbability": [...],
    "initialTotalProbability": [...],
    "initialSeverity": [...],
    "initialRiskEvaluation": [...],

    "residualHarmProbability": [...],
    "residualOccurrenceProbability": [...],
    "residualSeverity": [...],
    "residualTotalProbability": [...],
    "residualRiskEvaluation": [...],

    "hazardousSituations": [...],
    "eventSequences": [...],
    "eventSteps": [...],

    "hazards": [...],
    "harms": [...],

    "dataByHazardType": {
      "[Hazard type value]": {
        "initialTotalProbabilityMatrix": {...},
        "initialRiskEvaluationMatrix": {...},
        "residualTotalProbabilityMatrix": {...},
        "residualRiskEvaluationMatrix": {...},
      }
    }
  }
}

Details on how to define each matrix / hazard type based configuration can be found by inspecting the relevant field in the advanced settings page.

Internal IDs

Item types

• ADVISORY (Vulnerability Advisory)

• ANOMALY (Anomaly)

• CAPA (CAPA)

• CHANGE_REQUEST (Change Request)

• COMPLAINT (Complaint)

• CONFIGURATION_ITEM (Configuration Item)

• DEPENDENCY (Dependency)

• HARDWARE_ITEM (Hardware Item Spec)

• REQUIREMENT (Requirement)

• RISK (Risk)

• SOFTWARE_ITEM (Software Item Spec)

• TASK (Task)

• TEST_EXECUTION (Test Execution)

• TEST_PLAN (Test Plan)

• TEST_PROTOCOL (Test Case)

• VULNERABILITY (Vulnerability Impact Assessment)

Document types

• AUTHORITY_MATRIX (Authority Matrix)

• CHANGE_MANAGEMENT_FILE (Change Management File)

• CHANGE_REQUEST_REPORT (Change Request Verification Report)

• CLOUD_CONFIG_REPORT (Cloud Configuration Report)

• CODE_REVIEW_REPORT (Code Review Report)

• CYBER_RISK_MANAGEMENT_FILE (Cyber Risk Management File)

• PROBLEM_REPORT (Problem Report)

• RELEASE_HISTORY (Release History)

• RELEASE_NOTES (Release Notes)

• RISK_CONTROL_FILE (Risk Control Matrix)

• RISK_MANAGEMENT_FILE (Risk Management File)

• RISK_MATRIX (Risk Matrix)

• SOFTWARE_ARCHITECTURE_CHART (System Architecture Chart)

• SOFTWARE_DESIGN_SPECIFICATION (System Design Specification)

• SOFTWARE_DESIGN_STRUCTURE_MATRIX (System Design Structure Matrix)

• SOFTWARE_REQUIREMENTS_SPECIFICATION (System Requirements Specification)

• SOUP_DEPENDENCIES (SBoM – SOUP – Software Configuration Report)

• TEST_PLAN (Test Plan)

• TESTING_REPORT (Testing Report)

• TRACEABILITY_MATRIX (Traceability Matrix)

• TRAINING_STATUS_REPORT (Training Status Report)

• UNRESOLVED_ANOMALIES (Unresolved Anomalies)

• VULNERABILITY_REPORT (Vulnerability Report)

Relations

• AFFECTS (affects)

• ASSESSES (assesses)

• CONTAINS_TESTS (contains)

• CUSTOM (custom)

• EXECUTES (executes)

• FOUND_ANOMALY (found anomaly)

• FULFILLS (fulfills)

• HAS_PARENT (has parent)

• HAS_ROOT_CAUSE (has root cause)

• IMPLEMENTS (implements)

• INITIATES_THREAT (initiates threat)

• INTRODUCES_RISK (introduces risk)

• IS_CONTAINED_IN_TRUST_BOUNDARY (contained in)

• IS_EXPLOITED_BY (is exploited by)

• IS_EXPOSED_BY (is exposed by)

• IS_IMPACTED_BY (is impacted by)

• IS_RELATED_TO (is related to)

• IS_REPORTED_BY (reported by)

• IS_RISK_CONTROLLED_BY (is risk-controlled by)

• IS_TESTED_BY (dependency is tested by)

• LINKS_TO (dependency links to)

• RELATES_TO (relates to)

• RESOLVED_BY (is resolved by)

• RESULTS_IN (results in)

• TESTS (tests)

• USES (uses)

• USES_DEPENDENCY (uses dependency)

Built-in fields

• acceptedVersions (Accepted version(s))

• affectedItems (Affected items)

• affectedLibraryVersionRange (Affected library version ranges)

• aliases (Aliases)

• anomalyClassification (Anomaly classification)

• changeTypes (Change type): ADAPTIVE (Adaptive), CORRECTIVE (Corrective), PERFECTIVE (Perfective), PREVENTIVE (Preventive)

• cisaActionDue (CISA action due)

• cisaExploitAdd (CISA exploited add)

• cisaRequiredAction (CISA required action)

• cisaVulnerabilityName (CISA vulnerability name)

• complainantContactInformation (Complainant contact information)

• complaintReceivedDate (Date received)

• complaintType (Complaint type): ADVERSE_EVENT (Adverse Event), OTHER (Other), PRODUCT_COMPLAINT (Product Complaint), SEVERE_ADVERSE_EVENT (Severe Adverse Event)

• configurationItemVersion (Configuration item version)

• containedTests (Contained tests)

• correctiveActions (Corrective actions)

• cweIds (CWE IDs)

• description (Description)

• endOfLife (End of life)

• endOfLifeDescription (End of life description)

• environment (Environment)

• executedProtocol (Test being executed)

• expectedBehavior (Expected behavior)

• externalId (CVE ID)

• foundAnomalies (Found anomalies)

• fulfilledRequirements (Fulfilled requirements)

• harm (Harm)

• hazard (Hazard)

• hazardousSituation (Hazardous situation)

• hazardTypeText (Hazard type; Jira field key hazardTypeChoice)

• homepageUrl (Homepage)

• impactCriticality (Impact criticality): HIGH (High), LOW (Low), MEDIUM (Medium)

• impactOfChange (Impact of change)

• impactOnSystem (Impact on system)

• impactScope (Impact scope): LARGE (Large), MEDIUM (Medium), SMALL (Small)

• implementedItems (Implemented items)

• initialHarmProbabilityText (Initial likelihood of harm (P2); Jira field key initialHarmProbability)

• initialOccurrenceProbabilityText (Initial likelihood of occurrence (P1); Jira field key initialOccurrenceProbability)

• initialRiskEvaluationText (Initial risk evaluation; Jira field key initialRiskEvaluation)

• initialSeverityText (Initial severity; Jira field key initialSeverity)

• initialTotalProbability (Initial total probability)

• inputs (Inputs)

• interfaces (Interfaces)

• introducedInVersion (Introduced in version)

• investigation (Investigation)

• investigationCompletedDate (Date investigation completed)

• investigationRequired (Investigation required): NOT_REQUIRED (Not required), REQUIRED (Required)

• isRiskAcceptable (Risk acceptability): ACCEPTABLE (Acceptable), NOT_ACCEPTABLE (Not acceptable)

• issuesUrl (Issues URL)

• levelOfSupport (Level of support)

• levelOfSupportDescription (Level of support description)

• license (License)

• linksTo (Dependency links to)

• manufacturer (Manufacturer)

• medicalDeviceName (Name of medical device)

• modifiedAt (Modified at)

• newItems (New items)

• notes (Additional notes)

• observedBehavior (Observed behavior)

• obsoleteInVersion (Obsolete in version)

• originalCustomerComplaint (Original customer complaint)

• outputs (Outputs)

• parentHardwareItems (Parent hardware items)

• parentRequirements (Parent requirements)

• parentSoftwareItems (Parent software items)

• preventiveActions (Preventive actions)

• problemReportType (Problem report type): ADAPTIVE (Adaptive), CORRECTIVE (Corrective), PERFECTIVE (Perfective), PREVENTIVE (Preventive)

• publishedAt (Published at)

• rationale (Rationale)

• rationaleForDeferringResolution (Rationale for deferring resolution)

• reasonForChange (Reason for change)

• regions (Regions)

• relatedIssues (Related issues)

• relatedItems (Related items)

• relevantStandards (Relevant standards)

• reliabilityImpact (Reliability impact)

• reliabilityImpactJustification (Reliability impact justification)

• replyToComplainant (Reply to complainant)

• reportedBy (Reported by)

• reportedOn (Reported on)

• reporterType (Reporter type): EXTERNAL (External), INTERNAL (Internal)

• repositoryUrl (Repository URL)

• requirementContext (Context): CLINICAL (Clinical), EXTERNAL (External), REGULATORY (Regulatory), SAFETY (Safety), SECURITY (Security)

• requirementType (Requirement type): ACCOMPANYING_DOCUMENTS (Accompanying documents), ALARMS_WARNINGS_MESSAGES (Alarms, warnings and messages), DATA_AND_DATABASES (Data and databases), DOCUMENTATION (Documentation), ENVIRONMENT (Environment), ESSENTIAL_FUNCTION_PROTECTION (Essential function protection), EXTERNAL_INTERFACES (External interfaces), FAULT_HANDLING (Fault handling), FUNCTIONAL (Functional), IMMUNITY_SHARED_HARDWARE (Immunity to unintended influence using shared hardware), INSTALLATION_AND_ACCEPTANCE_ONSITE (Installation and acceptance onsite), INTENDED_USE (Intended use), INTERFACES (System interfaces), INTEROPERABILITY (Interoperability), LEGAL (Legal), LOCALIZATION_AND_LANGUAGE_SUPPORT (Localization and language support), METHOD_OF_OPERATIONS_AND_MAINTENANCE (Method of operations and maintenance), PERFORMANCE (Performance), PRODUCT_CONFIGURATION_RECOVERY (Product configuration recovery by authenticated users), REGULATORY (Regulatory), RISK_CONTROL_INITIAL (Risk control based on initial risk assessment), SAFETY (Safety), SECURITY (Security/Privacy), SECURITY_DETECTION (Security detection), SOFTWARE_IO (Software I/O), SOFTWARE_SYSTEM (Software system), SOFTWARE_UPDATE_AND_DISTRIBUTION (Software update and distribution), SUSCEPTIBILITY_SHARED_HARDWARE (Susceptibility to unintended influence using shared hardware), SYSTEM (System), TECHNICAL (Technical), USABILITY (Usability), USE_CASE (Use case), USER (User/Marketing), USER_DOCUMENTATION_TO_BE_DEVELOPED (User documentation to be developed), USER_INTERFACE (User interface requirement), USER_INTERFACE_SPECIFICATION (User interface specification), USER_MAINTENANCE (User maintenance)

• residualHarmProbabilityText (Residual likelihood of harm (P2); Jira field key residualHarmProbability)

• residualOccurrenceProbabilityText (Residual likelihood of occurrence (P1); Jira field key residualOccurrenceProbability)

• residualRiskEvaluationText (Residual risk evaluation; Jira field key residualRiskEvaluation)

• residualSeverityText (Residual severity; Jira field key residualSeverity)

• residualTotalProbability (Residual total probability)

• resolvedBy (Resolved by)

• riskAssessmentMethodologiesText (Risk assessment methodologies; Jira field key riskAssessmentMethodology)

• riskBenefitAnalysis (Benefit-risk analysis)

• riskClass (Safety risk class): CLASS_A (Class A), CLASS_B (Class B), CLASS_C (Class C), MDDS (MDDS), NONE (None)

• riskControlMeasures (Risk control measures)

• riskControlOptions (Risk controls description)

• riskLevel (Risk level): MAJOR (Major), MINOR (Minor), MODERATE (Moderate), null (Unspecified)

• risks (Introduced risks)

• rootCauseAnalysis (Root cause analysis)

• securityImpact (Security impact)

• securityImpactJustification (Security impact justification)

• securityRiskClass (Security risk class): HIGH (High), LOW (Low), MEDIUM (Medium)

• sequenceOfEvents (Sequence of events)

• softwareItemType (Software item type): CONTRACTED (Contracted), FUNCTION (Function), INTERFACE (Interface), LIBRARY (Library), MDDS (MDDS), MEDICAL_DEVICE (Medical Device), SAFETY (Safety), SECURITY (Security), SOUP (SOUP)

• steps (Steps)

• systemCategoriesText (System categories; Jira field key systemCategories)

• testedBy (Dependency is tested by)

• testEnvironments (Test environments)

• testResult (Test result): FAIL (Fail), PASS (Pass), PASS_WITH_EXCEPTION (Pass with exception)

• tests (Tested items)

• testType (Test type): VALIDATION (Validation), VERIFICATION (Verification), VERIFICATION_INTEGRATION (Verification (integration)), VERIFICATION_REGRESSION (Verification (regression)), VERIFICATION_SYSTEM (Verification (system)), VERIFICATION_UNIT (Verification (unit))

• usedDependencies (Used dependencies)

• usedItems (Used items)

• usedServices (Used services)

• vulnerabilityReferences (References)

• vulnerabilitySeverity (Severity classification)

• vulnExternalUrl (External URL)

• withdrawnAt (Withdrawn at)