IF From Status IS

Runs the ops nested underneath it when the topic is sitting in one of the statuses you pick. It is how a rule workflow says "from here, these are the exits", with the exits declared as transition ops inside the block.

Change Topic Status If Matches has a From Status field that tests the same thing for one transition. Use the field when a single transition is involved. Use this op when several transitions leave the same status, or when you want other work, such as a notification, to happen on the way out.

Fields

From Status

The statuses that open the block. Pick as many as you want; the topic is in one status at a time, so one match is enough. The form will not let you save the op with the box empty.

Pick from the list rather than typing. The box lists status names and stores status identifiers, and it offers every status in the installation rather than only the ones the rule's categories use. A status the topic's category does not carry can never be the topic's current status, so a block gated on it never runs.

Variables are not expanded here. A ${var} typed into this box is compared against status identifiers as written and never matches.

The side effect

This op records the statuses you picked, and the record survives for the rest of the rule. It is written whether the test passed or not.

Change Topic Status and Change Topic Status If Matches both read that record when their Deployment Type is anything other than No Job, and restrict their origin statuses to it. That shows up when Clarive lists the complete workflow for a category: a transition set to Promote draws its arrow only from the statuses the record holds, instead of from every status in the category.

A skipped block still leaves its record behind, so a promotion op placed after an unrelated status gate can end up narrowed by it. And the record in force is whatever the last of these ops to have run wrote, which is not necessarily the one the transition sits inside. Nesting does not scope it and leaving the block does not restore the previous value.

With Deployment Type left at No Job, none of this applies.

When the test is skipped

Clarive sometimes runs a workflow rule to collect every transition it could ever produce rather than the ones available right now. The category workflow view is built that way, and so is the candidate list behind the Promote and Demote menus. In that mode this op always opens, whatever you picked, which is exactly why the record described above exists: it is what keeps a promotion from being drawn out of every status in the category.

A topic with no status recorded yet fails the test outside that mode, so a block gated this way does not apply while a topic is being created.

Combining with other ops

Nest Change Topic Status inside. That op starts its transition from wherever the topic is, and this gate is what decides where "wherever" is allowed to be.

Put IF Role IS inside or outside this op to require a role as well. The two nest in either order.

ELSE placed straight after works as the other branch, with one caveat: in listing mode the test always passes, so the ELSE side never reaches the category workflow view.

For conditions on topic fields rather than status, use IF var condition THEN.

Statuses are administered under statuses, and the identifiers the picker stores come from there.

Examples

Everything that can leave review, gathered in one block.

IF From Status IS   In Review
  Change Topic Status
    To Status         Approved
    Deployment Type   No Job
  Change Topic Status
    To Status         Rejected
    Deployment Type   No Job

A promotion that may start from either of two statuses, with the role gate inside.

IF From Status IS   Approved, Scheduled
  IF Role IS        release_manager
    Change Topic Status
      To Status         In PROD
      Deployment Type   Promote