Adds a rule to a phase's approval configuration. A rule defines, through conditions, when it applies to a card, and who the approvers responsible for voting are once it is triggered.Rules must be sent one at a time: sending an array with more than one rule in a single call is not accepted. To register several rules, repeat this call once for each rule.The approvers.type field defines the voting format: alternative corresponds to a horizontal flow, where any approver in the level decides, without necessarily following the order of the levels defined in hierarchy; cumulative corresponds to a vertical flow, where the levels in hierarchy are walked through in a chain — level 1 must complete its approval before level 2 is enabled to vote, and so on. The hierarchy[].quantity field defines how many approvers from that level must vote for the level to be considered complete.Each user in hierarchy[].users is identified by their user identifier, obtained from the company's user listing — which also returns name and email, useful for locating the right user before noting down the identifier. Users without access to the flow cannot be added as approvers. Within conditions, on the other hand, when a rule needs to filter by the author of a previous action on the card — such as who is responsible for a technical opinion — the correct identification is by name or email, not by an internal user identifier.Accepted condition operators are: gte, lt, eq, in, all, contain, is-empty and is-not-empty. There are no gt or lte operators — to express 'greater than X' use gte with the value X+1, and for 'less than or equal to X' use lt with the value X+1.
Requisição
Parâmetros de Caminho
Parâmetros Bodyapplication/jsonNecessário
Examples
Respostas
🟢201Rule created
application/json
The rule was added to the approval configuration successfully.