Task statuses
The task status is the project status for a requirement or control. SD Elements includes three main statuses:
-
Complete
-
Incomplete
-
Not-applicable
Custom task statuses can be created based on any of these three. Organizations may want to use a unique task status to better match their team’s processes and workflow.
For example, teams may not complete all tasks in a project, and often prefer to accept the risk or defer the work. An SD Elements super user can create task statuses, such as “Risk Accepted” or “Deferred”, and map them to one of the three main statuses using the "meaning" attribute.
We recommend only using built-in task statuses whenever possible, because the user experience and integrations are specifically designed around them.
Details
A task status has the following fields:
-
Slug: A unique name for the status.
-
Icon: An image representing the status.
-
Name: The name of the status.
-
Meaning: A mapping to one of the three main statuses.
-
Default: An indicator whether or not tasks added to a project should be set to this status by default.
-
Only one task status can be set to "default" at any given time.
-
-
Requires comment: An indicator whether a user must enter a comment before setting a task to this status.
Create a custom task status
Create a new task status by following the steps below.
-
The user has the system Super User permission.
-
From the gear icon settings menu, select Task Status.
-
Click Add Status.
-
Fill in the required fields.
-
Click Add Status.
The new task status is now available in all projects.
Delete a custom task status
Delete a custom task status by following the steps below.
-
The user has the system Super User permission.
-
From the gear icon settings menu, select Task Status.
-
Select the desired task status.
-
Click Delete Status.
-
Acknowledge the warning.
-
Click Confirm.
The selected task status is permanently deleted. All instances of the status is replaced with its underlying built-in task status.
When to create a custom task status
You may encounter situations where a custom task status is important for enterprise adoption. For example, if there is already a process for adopting software security requirements, you may need to reflect the existing process statuses.
Another reason for adding a custom task status is when organizations want to reflect a difference between a task that is incomplete versus a task that will never be worked on. In this case, you may want to create a custom task status for “Risk Accepted”. You can determine this by interviewing key stakeholders when you plan for an SD Elements deployment. In particular, ask if the current status conveys enough information for reporting purposes.
It is highly recommended that you make this kind of change early on, ideally before you model any projects in SD Elements. While there is no defined hard limit for the number of custom task statuses, adding more than two will likely significantly degrade the user experience. Additionally, task status names should be short because certain views may cut off any that are too long.
-
Are there any pre-existing security requirements with different statuses that are not accurately reflected in SD Elements?
-
Do the three built-in statutes provide sufficient data for key stakeholders?