IF Role IS

Runs the ops nested underneath it when the user holds at least one of the roles you pick. It is the role gate for a rule workflow: put a group of transitions inside it and they disappear for everyone outside those roles.

Change Topic Status If Matches has a Roles field that does the same test for a single transition. Use the field when one transition is involved, and this op when several transitions share the same gate and you would rather state it once.

Fields

Roles

The roles that open the block. Pick as many as you want; one match is enough. The form will not let you save the op with the box empty. The box lists roles by name and stores their identifiers, which is what the examples below and the workflow grid show.

Roles are counted against the topic in front of the user, not against the user's account in general. A role granted through one project and not another lets the same person through on one topic and not on the next. Root users hold every role in the system, so every branch in the rule opens for them.

The op reads the roles the surrounding workflow run handed it. Put it in a rule that is not driving a topic workflow and there is nothing to read, so the block is skipped and no warning is raised.

The picker also lists your global variables. They do not work here. A variable chosen in this box is stored as the placeholder text and compared against role identifiers as written, so it never matches and the block never runs. The Roles field on Change Topic Status If Matches does expand variables, which is why the two boxes look identical and behave differently.

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, and an ELSE attached to it never contributes. The category workflow view shows that result straight, so a transition you gated to one role is listed there for everyone. The Promote and Demote menus narrow their candidates afterwards against an ordinary run of the same rule, so the gate does bite there.

To confirm a role gate, open a topic as the user you are testing rather than reading it off the workflow view.

Combining with other ops

Nest Change Topic Status inside this op. That op has no role field of its own and hands the transition to every role the user holds, so a gate around it is the usual way to narrow it.

Stack the gates when you need two conditions at once. This op inside IF Project IS gives you a transition for one role on one set of projects, and the order of the two does not matter.

For conditions on anything other than roles, statuses and projects, use IF var condition THEN against the values the rule already carries.

Roles are administered under roles, and the identifiers the picker stores come from there.

Examples

Two exits from review, both restricted to approvers.

IF Role IS   approver
  Change Topic Status
    To Status         Approved
    Deployment Type   No Job
  Change Topic Status
    To Status         Rejected
    Deployment Type   No Job

A role gate inside a project gate. Only release managers working on the listed projects get the promotion.

IF Project IS   myapp, myapp_api
  IF Role IS    release_manager
    Change Topic Status
      To Status         In PROD
      Deployment Type   Promote