Custom rules allow you to manipulate the default business logic of Targetprocess.
For instance you can tell Targetprocess to automatically move the parent User Story into progress as soon as you move the first Task of a User Story into progress or you close a parent User Story as soon as all its Tasks (and Bugs) are done.
Activation and deactivation
You can find the rules in Settings → Custom Rules.
Only Administrators can control custom rules. Rules are not restricted to any project or process, they affect globally all data in your account.
Just activate the rules that best fit your needs, by clicking on the green "Activate" button next to each rule.
Hints and technical details
There are some things to keep in mind while you use custom rules.
Rules are executed by a special Rule Engine user, who has any permissions.
If a user, lets call her Alice, moved a user story to “In Progress” state, while having no rights to edit a feature, the activated rule “Start a Feature when a User Story has been started” will move the feature successfully anyway.
Rules that mention “Planned” state will work correctly only if the state is marked as “Planned” in the process setup (just naming it “Planned” won’t suffice).
No error message is shown if a rule fails; however, it may have perfectly legit reason to fail (e.g., a team should be assigned to a project). Please check System Log if you see that a rule wasn’t applied.
The rules are be available via REST — at /api/v1/CustomRules.
List of available rules
|Close a User Story when all its Tasks are done||When a Task is closed, check all the other Tasks in its User Story. If they all have been closed, close the User Story as well.|
|Close a Bug's User Story if all its Bugs and Tasks are closed||When a Bug is closed, check all the other Tasks and Bugs in its User Story. If they all have been closed, close the User Story as well.|
|Close a Task's User Story if all its Tasks and Bugs are closed||When a Task is closed, check all the other Tasks and Bugs in its User Story. If they all have been closed, close the User Story as well.|
|Start a User Story when a Task has been started||After the first Task in a User Story is moved to a state that's not Initial or Planned, move this User Story to the first state after Planned.|
|Start a Feature when a User Story has been started||After the first User Story in a Feature is moved to a state that's not Initial or Planned, move this Feature to the first state after Planned.|
|Assign a Task to the Person who started it||After the Task is moved from an Initial or Planned state to any other state, assign it to the Person who moved it. "Developer" role must be available in the Task workflow.|
|Assign the people working on a User Story to a newly created Task||Everyone who is assigned to the parent User Story will be assigned to a new Task.|
|Assign a User Story's Feature to a Bug||When a Bug is assigned to a User Story, also assign this Bug to User Story's Feature.|
|Assign a Feature's Project to a User Story||When a User Story is assigned to a Feature, move this User Story to the Feature's project.|
|Assign the Feature's Team to all its children||When a Feature is assigned to a Team, all the Feature's Bugs and User Stories are assigned to the same Team. Only the bugs directly linked to the Feature will be assigned.|
|Assign a Project's Team to a User Story||When a User Story is assigned to a Project, assign this User Story to this Project's Team. The Team will be assigned if it's the only Team assigned to the Project.|
|Move a Feature to “Planned” state when its Release is set||Affects only the Features in the Initial state. The state should be marked as “Planned” in the workflow setup.|
|Move a User Story to “Planned” state when its Planned Start Date is set||Affects only the User Stories in the Initial state. The state should be marked as “Planned” in the workflow setup.|
|Reschedule Features, User Stories and Bugs in a Release||When a Release is moved to a later Start date (e.g., it will start 7 days later), the Planned Start Dates and the Planned End Dates for Features, User Stories and Bugs are updated accordingly (increased by 7 days).|
|Reschedule User Stories and Bugs in an Iteration||When an Iteration is moved to a later Start Date (e.g., it will start 7 days later), the Planned Start Dates and the Planned End Dates for User Stories and Bugs are updated accordingly (increased by 7 days).|
|Assign the User Storie`s Team to all its children||When a User Story is assigned to a Team, all the User Story's Tasks and Bugs are assigned to the same Team. Only the bugs directly linked to the User Story will be assigned.
When this rule is active you can change a Team for all child entities of a User Story following the steps below:
If you just move the User Story across two Teams or assign the User Story to one more Team, it won't change current Team assignment for Tasks and Bugs of this User Story
|Close a Request when all related outbound entities are closed||Request is moved to the Final state when all its related outbound entities are closed. Request in the Final state is moved to the Initial state when open related outbound entity is added or any of its related outbound entities are reopened.|
|Close a Request when all related inbound entities are closed||Request is moved to the Final state when all its related inbound entities are closed. Request in the Final state is moved to the Initial state when open related inbound entity is added or any of its related inbound entities are reopened.|
Rules configured in Practice settings
|Planning||User Story Effort = Sum of Tasks Effort||When the rule is active and new child Task is added to a User Story, then the effort of this Task is automatically subtracted from the User Story effort.|
|Planning||Close Tasks when User Story is closed||When you have a User Story with several Tasks and change state of the User Story to final - move all Tasks into final state as well.|
|Time Tracking||Close User Story / Task / Bug as Done if time remaining is 0||When user adds time record to User Story / Task / Bug and specify zero time remaining, assignable will be closed.|
Automation Rules allow to extend Targetprocess functionality even further. This feature adds the ability to automatically react to a change in Targetprocess or an event in a third party service, execute custom logic, and form a pack of changes that will be made in Targetprocess as a result.
a sales representative
Get a live
Let one of our product specialists create your account
and shape Targetprocess for your company needs.