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"
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
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 "Folder"
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"
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"
Remove the "Backend" option for the "CAPA type" field
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
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.
Track various fields in Ketryx
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. 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.
Use the name "is child of" instead of the default relation name "has parent"
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
Configure custom status names used in Xray
Custom document types
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.
Add custom document types for Manual and SOP
Custom item types
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 types for Folder and Note
Add custom item type that can be edited in Ketryx
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
Authentication configuration
Authentication providers
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/oktaSet the Sign-out redirect URL to
https://app.ketryx.comMake 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
Configure Okta authentication (based on a CLIENT_ID and CLIENT_SECRET retrieved from Okta, and an appropriate Okta URL)
Allow authentication via Okta in addition to email-based authentication
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:
fieldValuesdefines values that are always set, regardless of any explicit value defined on the Jira issue.fieldDefaultsdefines 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
Map Stories with the "Ketryx" label to Requirements
Map Stories with the "Ketryx" label to Requirements, and (more specifically) Stories with the label "UseCase" to Requirements with a type of "Use case"
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
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
Read a custom description field from Jira
Ignore a certain field value from Jira
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 toapprovedTransitionStatusif defined (otherwise the status remains the same), and it will be a controlled record depending on the new status'isControlledsetting. By default, this is true for the 'Resolved' status.approvedTransitionStatus: The status to transition to upon approval, ifshouldTransitionWhenApprovedistrue. If this is set tonull, 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 tonull, 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 inuncontrolledFieldNamesare 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'sisControlledwill 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. ifkeepApprovalsWhenTransitionedTois 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
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"
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
Enable Ketryx Intelligence (KI) Sidebar
Whether to enable the KI 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
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.
AI prompt suggestions
Predefined prompts for the Ketryx Intelligence sidebar.
Use custom prompt suggestions
AI feature configuration
Custom configuration of the AI-based features such as the item assistant.
Use a custom OpenAI instance on Azure
Use a custom OpenAI endpoint
Enable enhanced AI-based item creation and editing
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.
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
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
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).
Track the extra fields "Acceptance Criteria" and "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
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"
Enforce that all Test Cases that are risk controls are included 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
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)
(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)
(RTM v2) Trace "Use case" requirements to other requirements to specs to tests (overriding the behavior from the project's schema config)
(RTM v2) Only require validation of requirements (overriding the behavior from the project's schema config)
(RTM v2) Add "Intended use" requirements to the first column (rather than ignoring them, which would be the default)
Enable the RTM approval workflow for the traceability page
Additional traceability configurations
Other traceability configurations that are selectable in addition to the default configuration.
Two additional traceability configs
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).
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.
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)
Alphabetical version identifiers (three components, with the second and third one being optional, but being normalized to an empty part)
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"
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
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:
Rename threat rich text field
Hide all rich text fields
Bypass adding all threat modeling fields to the vulnerability impact assessment form
New in 2.11
Add another rich text fields. In this case, the default field must be included in the list.
Bypass adding all threat modeling fields to the vulnerability impact assessment form
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.
Default configuration object:
Use a custom assessment heading
Use a custom resolution configuration
Rename risk and mitigation rich text fields
Hide all rich text fields
Bypass adding all vulnerability management fields to the vulnerability impact assessment form
New in 2.11
Allow only software item specs and test cases as mitigation items
Bypass adding all vulnerability management fields to the vulnerability impact assessment form
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
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
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 recordreleaseApproval: Approval of a version/releasemilestoneApproval: Approval of a milestonedocumentApproval: Approval of a document in the EDMStestPlanApproval: Approval of a release test planvulnerabilityApproval: Approval of a vulnerability
See also more details in the webhooks API reference.
Send a webhook upon item record approval
Send a webhook upon version release approval, using a GET request with a custom Authorization header
Use Ketryx-specific Jira configuration
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.
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
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
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.
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
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.
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
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
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
System Requirements Specification
Customization of SRS output documents.
Omit a dedicated "Other" section heading if it is the only section in the document
Requirements Traceability Matrix
Customization of RTM output documents.
Omit use cases and specs from the RTM document
Do not show excluded tests at all
Do not show excluded tests if there is no "inherited" test in the previous release
Rename the use-case-related columns, and omit the "Requirement type" column
Risk Matrix
Customization of Risk Matrix output documents.
Rename some columns, and omit the "System categories" column
Release history
Customization of Release History documents.
Default values:
Remove the Scope description section from the release history document
Include the V&V section in the release history document
Release Notes
Customization of Release Notes documents.
Default values:
Remove the Scope description section from the release notes
Include the V&V section in the release notes
Only include certain user requirements in the release notes
Only include corrective anomalies in the release notes
SBoM – SOUP – Software Configuration report
Customization of SBoM – SOUP – Software Configuration Report documents.
Rename the column "Dependency name" to "Name"
Omit the "Ecosystem" column
Test Plan
Customization of Test Plan documents.
Omit automated tests from the Test Plan Word document
Testing Report
Customization of Testing Report documents.
Only show the last (effective) test execution for each test in the Testing Report Word document
Risk Management File
Customization of Risk Management File documents.
Omit the risk evaluation matrix section from the document
Omit the general information section from the document
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
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
Normalization
Document normalization settings.
Enable embedding of EDMS documents
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.
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
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.
Risk configuration
Hazardous situations
Customization of hazardous situation values.
Set new hazardous situation values
Event sequences
Customization of event sequence values.
Set a new event sequence value
Event steps
Customization of event step values.
Set new event step values
Hazards
Customization of hazard values.
Set new hazard values
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
The matrix should cover all possible combinations. Doing otherwise will lead to unexpected behavior by the system.
Set new matrix values
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:
The matrix should cover all possible combinations. Doing otherwise will lead to unexpected behavior by the system.
Set new matrix values
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:
The matrix should cover all possible combinations. Doing otherwise will lead to unexpected behavior by the system.
Set new matrix values
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:
The matrix should cover all possible combinations. Doing otherwise will lead to unexpected behavior by the system.
Set new matrix values
Hazard type-specific configuration
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.
Set Acoustic hazard type-specific initial total probability matrix
Internal IDs
Item types
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)
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)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)
Relations
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)
Built-in fields
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 keyhazardTypeChoice)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 keyinitialHarmProbability)initialOccurrenceProbabilityText(Initial likelihood of occurrence (P1); Jira field keyinitialOccurrenceProbability)initialRiskEvaluationText(Initial risk evaluation; Jira field keyinitialRiskEvaluation)initialSeverityText(Initial severity; Jira field keyinitialSeverity)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 keyresidualHarmProbability)residualOccurrenceProbabilityText(Residual likelihood of occurrence (P1); Jira field keyresidualOccurrenceProbability)residualRiskEvaluationText(Residual risk evaluation; Jira field keyresidualRiskEvaluation)residualSeverityText(Residual severity; Jira field keyresidualSeverity)residualTotalProbability(Residual total probability)resolvedBy(Resolved by)riskAssessmentMethodologiesText(Risk assessment methodologies; Jira field keyriskAssessmentMethodology)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 keysystemCategories)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)
Last updated
Was this helpful?