IF Project IS

Runs the ops nested underneath it when the topic belongs to one of the projects you pick. Use it to give one set of projects a transition the rest do not get, without splitting the category into two workflows.

This is the only workflow IF op that looks at the topic's contents rather than at the user or the status. Pair it with IF Role IS when the answer depends on both.

Fields

Projects

The projects that open the block, sitting on its own under the IF INPUT MATCH... heading. The picker offers project resources only, and takes as many as you want; one match is enough. The form will not let you save the op with the box empty.

The comparison is against the projects linked to the topic directly. Project hierarchy is not walked, so a topic attached to a child project does not match when you pick the parent, and a topic attached to the parent does not match when you pick the child. List every project you mean.

The box holds picked projects and nothing else. It does not carry the ${var} entries that other resource pickers offer, typing a name that is not a project leaves the box unchanged, and a variable that reaches the list some other way is compared as literal text and never matches.

When there is no topic yet

The op needs a saved topic to read project links from. Consulted before the topic exists, there are no links to compare and the block does not run, so a transition gated this way is not available at creation time.

Clarive also runs workflow rules in a listing mode, to collect every transition a category could ever produce rather than the ones available right now. The category workflow view works that way, and in that mode this op always opens, whatever you picked, so a project-specific transition is drawn there for every project. Open a topic to see the real answer.

Who the gate does not stop

The gate only narrows the list for users whose transitions come out of the rule. A root user, or anyone holding Change a topic to any available status in its category for the category, is offered every status the category has without the rule being consulted, and the same list is what gets checked when the change is saved. Gating a transition by project keeps it tidy for everyone else and stops nobody with that permission.

Combining with other ops

Nest Change Topic Status or Change Topic Status If Matches inside to make the transition itself project-specific.

IF Role IS is the usual partner, and the two nest in either order. When the roles you would test are granted per project anyway, the role gate on its own already covers much of the same ground.

IF From Status IS adds the origin status to the gate.

For a condition on anything other than the project itself, use IF var condition THEN. The rule arrives holding the topic's project list and the status it is moving from, so neither needs loading. Topic fields are not in there, and reading one means loading the topic first.

Examples

One set of projects gets a direct path to production; everything else in the category does not.

IF Project IS   myapp_api, myapp_web
  Change Topic Status
    To Status         In PROD
    Deployment Type   Promote

A project gate with a role gate inside it, so the transition needs both.

IF Project IS   bar_svc
  IF Role IS    release_manager
    Change Topic Status
      To Status         Approved
      Deployment Type   No Job