Advanced Settings
Reference of advanced settings for Ketryx organizations and projects
Last updated
Was this helpful?
Reference of advanced settings for Ketryx organizations and projects
Last updated
Was this helpful?
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 . By design, not all internal settings are exposed. Also note that some parameters might change in future releases.
Advanced settings are generally specified as 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 section at the end of this reference.
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.
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.
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.
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.
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.
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.
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.
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.
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. By default, the names as displayed in Ketryx are used.
Note that the direction of the relation in Jira ("inward" vs. "outward") does not matter, as long as the name matches.
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.
A list of custom document types to provide better flexibility in managing documents in your projects' EDMS'.
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.
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.
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.
Whether to maintain Ketryx-defined Jira fields in a connected Jira instance. Enabled by default.
Map users from external systems to Ketryx users, based on their email address. Supported by select integrations only (currently Jama).
Custom authentication providers for this organization.
Supported properties are email, okta, and customOAuth.
This needs to be configured in combination with a custom email domain for this organization (managed by Ketryx Support).
For authentication via Okta, create a new App Integration in your Okta instance and configure it in the following way:
Use "OIDC - OpenID Connect" authentication with the application type "Web Application"
For Grant type, choose "Client acting on behalf of a user" via an "Authorization Code"
Set the Sign-in redirect URL to https://app.ketryx.com/api/auth/callback/okta
Set the Sign-out redirect URL to https://app.ketryx.com
Make sure that all desired members of the organization are assigned to the app in Okta
Configure the authentication provider in Ketryx using Okta's client ID, client secret, and issuer URL, as in the example below
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.
Mapping from Jira status names to Ketryx item states (OPEN, REOPENED, IN_PROGRESS, RESOLVED, or CLOSED).
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.
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.
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.
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.
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').
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.
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"].
Whether to enable the KI sidebar. Enabled by default.
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.
Whether Ketryx Intelligence should automatically identify and suggest items related to new items suggested 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.
Predefined prompts for the Ketryx Intelligence sidebar.
Custom configuration of the AI-based features such as the item assistant.
Whether Ketryx Intelligence (KI) should automatically identify and suggest items related to new items suggested or edited by it, in response to a user query. In addition, enabling this feature will cause KI to generate explanations for why it proposed various traceability relations. Note that 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.
Whether versions can be deleted by users with the appropriate permissions. Enabled by default.
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).
Status names to interpret as removal/obsolescence of an item w.r.t. releases, similarly to deleted items. Defaults to an empty list.
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".
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".
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).
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).
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.
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).
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.
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.
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.
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.
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.
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.
Other traceability configurations that are selectable in addition to the default configuration.
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.
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).
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).
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.
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.
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.
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.
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.
Whether to include related items in auto-created incremental releases. Disabled by default.
KQL filter for tests to exclude from the test plan in auto-created incremental releases.
Omitted documents in auto-created incremental releases.
Base ref name (glob pattern) to match against before auto-creating an incremental version. By default, the main analyzed branch is taken.
Head ref name (glob pattern) to match against before auto-creating an incremental version. By default, all head ref names are accepted.
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.
Whether to enable the threat modeling feature. Disabled by default.
Note that this feature requires configuration of certain Custom item types.
Configuration object for the threat modeling feature.
Any value not specifically set here will be used from the default configuration object.
Default configuration object:
New in 2.11
Whether to enable the vulnerability management feature. Enabled by default.
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.
Whether to share user reported vulnerabilities with all projects in an organization. Enabled by default.
If disabled, new vulnerabilities reported via the builds API or project import will only be visible within the current project.
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").
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
Determines whether Ketryx should configure the connected Jira 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 project is empty and the project is not in observe-only mode.
New in 2.12
Whether vulnerabilities are considered as configuration items. This setting is disabled by default.
When this option is enabled, manual vulnerabilities and automatically detected vulnerabilities with an impact assessment are treated as configuration items, allowing them to be managed like other items. More importantly, those vulnerabilities will be considered as release item types, meaning they may block a release if uncontrolled.
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.
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.
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.
Whether milestone documents are required to be up-to-date for the milestone to be approvable. Enabled by default.
Documents that should contain all items (independently of milestones), even if they are generated as milestone documents.
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.
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").
Whether to include a title page (on by default).
Whether to include a page listing the document version history (on by default).
Settings for all generated Word documents.
Use the setting for Custom template variables to define custom template variables such as $DOC_ID.
Settings for all generated Excel spreadsheets.
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.
Customization of SRS output documents.
Customization of RTM output documents.
Customization of Risk Matrix output documents.
Customization of Release History documents.
Default values:
Customization of Release Notes documents.
Default values:
Customization of SBoM – SOUP – Software Configuration Report documents.
Customization of Test Plan documents.
Customization of Testing Report documents.
Customization of Risk Management File documents.
Document normalization settings.
Whether to enable embedding of EDMS documents. Ketryx Intelligence uses these embeddings when answering user queries about their documents. If enabled, EDMS documents are sent to a zero data retention service for processing.
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 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.
Customization of hazardous situation values.
Customization of event sequence values.
Customization of event step values.
Customization of hazard values.
Customization of harm values. A harm may include an associated initial severity. If strict mode is enabled, it is recommended to add the severity.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
The matrix should cover all possible combinations. Doing otherwise will lead to unexpected behavior by the system.
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:
The matrix should cover all possible combinations. Doing otherwise will lead to unexpected behavior by the system.
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:
The matrix should cover all possible combinations. Doing otherwise will lead to unexpected behavior by the system.
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:
The matrix should cover all possible combinations. Doing otherwise will lead to unexpected behavior by the system.
Customization of hazard type-specific configuration.
The configuration takes on the following structure:
Details on how to define each matrix can be found by inspecting the relevant field in the advanced settings page.
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)
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)
CUSTOM_RELEASE_DOC (Custom document)
CYBER_RISK_MANAGEMENT_FILE (Cyber Risk Management File)
NORMALIZED_DOC (Normalized document)
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)
AFFECTS (affects)
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_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)
acceptedVersions (Accepted version(s))
affectedItems (Affected items)
anomalyClassification (Anomaly classification)
changeTypes (Change type): ADAPTIVE (Adaptive), CORRECTIVE (Corrective), PERFECTIVE (Perfective), PREVENTIVE (Preventive)
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)
description (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)
license (License)
linksTo (Dependency links to)
manufacturer (Manufacturer)
medicalDeviceName (Name of medical device)
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)
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)
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)
severityNumericScore (Severity Score)
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)
vulnExternalUrl (External URL)
See also more details in the .
Default date format to render date/time values in template-based documents. Placeholders as defined by can be used.
Default time zone to use for date/time values in template-based documents. Time zones are specified using their .