YouTrack InCloud 2017.3 Help


The requirements object serves two purposes.

  • First, it functions as a safety net. It specifies the set of entities that must exist for a rule to work as expected. Whenever one or more rule requirements are not met, corresponding errors are shown in the workflow administration UI. The rule is not executed until all of the problems are fixed.
  • Second, it functions as a reference. Each entity in the requirements is plugged into the context object, so you can reference entities from inside your context-dependent functions (like an action function).

There are two types of requirements: project-wide and system-wide.

  • Project-wide requirements contain a list of custom fields to be attached to each project which uses the rule as well as the required values from the sets of values for each custom field.
  • System-wide requirements contain a list of other entities that must be available in YouTrack. This includes users, groups, projects, issues, tags, saved searches, and issue link types.


Here's an example of a requirements statement that includes the definitions for a custom field and the values that are required for this field, followed by a list of system-wide requirements.

requirements: { P: { type: entities.EnumField.fieldType, name: 'Priority', M: { name: 'Major' }, Normal: {} }, ImportantPerson: { type: entities.User, login: 'superadmin' }, OurTeam: { type: entities.UserGroup, name: 'integration-team' }, Int: { type: entities.Project, name: 'Integration' }, Ref: { type: entities.Issue, id: 'INT-483' }, ToBeReleased: { type: entities.IssueTag, name: 'To be released' }, Untested: { type: entities.SavedQuery, name: 'Not tested yet' } Depend: { type: entities.IssueLinkPrototype, outward: 'is required for', inward: 'depends on' } }


Every entity that is specified in the requirements statement is identified by an alias. In the example above, the Priority field is assigned the alias P. When you assign an alias to an entity in the requirements, you use the alias to reference the entity in context. For example, the Priority field can be referenced as ctx.P, issue.fields.P, or issue.fields.Priority.

Each requirement that is specified in the requirements statement has the following properties:

typeThe data type of the entity. This property is required. Here is the complete list of types for custom fields:

The following types are used for system-wide entities:

saved searchesentities.SavedQuery
issue linksentities.IssueLinkPrototype
nameThe name of the entity. This property is optional. If a name is not set, it is considered to be equal to the alias.

For specific system-wide entities, this property is ignored entirely.

  • Users are identified by the login property.
  • Issues are identified by the id property.
  • Issue links are identified by the inward or outward properties.

In addition, there are properties that are only available for specific entity types. These properties are listed below:

custom fieldsvalueAny property that is defined for an entity that is not one of the known properties listed above is considered to be the requirement for a value in the set of values for a custom field. Each value property also has an optional name property.

In the example above, the value Major in the Priority custom field can be referenced as ctx.P.M or ctx.P.Major. The value of the custom field can be changed to Major with issue.fields.P = ctx.P.M;.

multiA Boolean property. When true, the custom field must store multiple values.
issue linksoutwardThe outward name of the issue link type.
inwardThe inward name of the issue link type.
usersloginThe login for a specific user. Used instead of the name property.
issuesidThe ID of a specific issue. Used instead of the name property.
Last modified: 17 November 2017