Finlay.worksBareBones Ticketing manual

Approvals

An approval request asks named people for a recorded decision on one ticket. This page covers sending a request, deciding one that is assigned to you, and using an approval to unblock a workflow action that is waiting for one.

Two kinds of request

Kind What it does What it cannot do
Ad hoc ticket approval Records a decision on this ticket. Use it when your process wants a decision written down. It never unblocks a gated workflow action, no matter who approves it.
Workflow transition gate Ties the request to one specific workflow action on this ticket. Approving it is what lets that action run. It does not move the ticket. You still perform the action afterwards.

Each request is also either Operational or Regulated. A regulated request asks the approver to acknowledge what their signature means and usually asks them to confirm their identity. A gated request uses whichever mode the gate is set to; you cannot change it.

Being asked to approve something gives that person a view of the ticket for the decision. It gives them no access to the department, the queue, projects, or anything else, and it does not make them a watcher or participant.

Ask for approval

  1. Open the ticket and find Approvals. You need Work access to the ticket.
  2. Select Request approval.
  3. Choose the purpose. If you need to unblock a gated action, open the request from that blocked action so it is tied to the right transition — several of the choices are then fixed for you and cannot be changed. Otherwise choose Ad hoc ticket approval.
  4. Set Approval modeOperational or Regulated — or read the value if the purpose fixed it for you. Regulated carries the electronic-signature requirement at decision time; operational does not.
  5. Search for and select at least one approver. They must be active internal staff. Customer Portal single sign-on (SSO) requesters and disabled accounts are refused.
  6. Write a Request note if it helps — 1,000 characters or fewer. Say what decision you need. Leave the approver's reasoning to them.
  7. Select Send request once.
  8. Confirm the request is now pending, the purpose is right, and everyone you meant to ask is listed.

You cannot give the same person a second pending approval on the same ticket. If they already have one, ask them about that one.

Sending the request is not the same as anyone being told about it. The product lines up a notification for each approver, but that is not proof the message was sent, arrived, or was read. It also gives nobody the right to decide — only the pending assignment recorded on the request does that, and only for the person it names. If an approver has not responded, chase them; do not send a second request.

The Approvals tab on the ticket summarises the position with six counters: total, pending, approved, rejected, regulated, and gate-bound. The last two are the ones to read carefully — regulated counts requests that go through regulated approval, and gate-bound counts those tied to a specific workflow transition. A request that is neither is an ad hoc request, and an ad hoc request cannot unblock a gated action. See Unblocking a gated workflow action.

Decide an approval assigned to you

Only assignments addressed to you are actionable. Holding department Admin does not let you decide someone else's assignment.

  1. Open My Approvals (Approval work). It states plainly: only approval assignments explicitly addressed to you appear here. The Active tab holds what is still pending; History holds what you have already decided. Use Refresh if you have just been asked.
  2. Select the pending assignment from the Active list.
  3. Read Decision channel, Workflow transition gate, Request note, Work-authorized ticket context, and Approval roster. The ticket description shown here is shortened to 700 characters.
  4. Confirm you understand what your decision means before you enter it.
  5. Under Decision, optionally record a Decision reason — up to 1,000 characters. It is not required (an operational decision can be made with Approve or Reject alone), but a reason is worth leaving where your process expects an audit note.
  6. If the request is regulated, you must additionally acknowledge the electronic-signature meaning shown on screen and re-verify your identity — an operational decision has neither of these steps and completes on the button alone.
  7. If you are asked to confirm your identity, do it as prompted. If you sign in with a password, you enter your current password. If you sign in through your organization's single sign-on, you need a current session that matches the account you are using — an old or mismatched one is refused.
  8. Select Approve or Reject once.
  9. Confirm your assignment is no longer pending and your decision is recorded.

Never put passwords or sign-in details into a decision reason.

What happens next:

  • A rejection ends the whole request.
  • An approval leaves the request pending until every named approver has approved.
  • Either way, the ticket does not move. A decision records a decision. Moving the ticket is a separate step someone performs afterwards.

Approval features record decisions and signatures inside the product. They do not by themselves make an organization compliant with any regulation.

Unblocking a gated workflow action

A gated action stays unavailable while the approval it needs is missing, pending, rejected, or does not match.

  1. Open the ticket and find the action under Workflow actions waiting on required information.
  2. Open the approval request from that action, so it is tied to that transition.
  3. Wait until every approver on that request has approved.
  4. Return to the ticket and refresh. The action should now appear under Available actions.
  5. Perform the action. See Workflow Actions.

Available actions and Workflow actions waiting on required information name the two groups of actions but are not printed on the screen. Look for the actions you can run now, and the separate ones that name something missing. A screen reader announces both names.

Which approval counts

A gate is satisfied only by a request that matches the action exactly: the same workflow, the same transition, the same version of the gate's settings, the same operational or regulated mode, and the same starting and ending statuses. This is why opening the request from the blocked action matters — it fills all of that in for you.

If more than one request matches exactly, the most recent matching one counts. "Most recent" means most recently created, not most recently decided.

A newer request that does not match exactly does not displace an older one that does, and it will not open the gate on its own.

A newer request that does match exactly replaces the older one, whatever state either is in. So if the gate is already open because an earlier matching request was approved, creating another matching request closes it again: the new one is the one that counts, and it is pending. The gate stays shut until that new request is approved too. Before you create a matching request, check whether the gate is already satisfied.

An ad hoc request never satisfies a gate, however senior the approver.

Approving a gate and signing at the moment of the transition are two separate things. Doing one does not do the other.

Performing the action records a cross-reference to the approval that let it through. It does not delete or overwrite the approval or anyone's decision.

If it does not work

  • The request would not send. Refresh the ticket and check you still have Work access, that everyone you selected is active internal staff, and that none of them already has a pending approval on this ticket.

  • Nobody has responded. Do not raise a duplicate request. Check the recorded request and its assignments first, then use Send reminder on the assignment that is still pending. The control is the reverse face of the button showing the assignment state, so it takes two clicks: one to reveal it, one to send.

    Reminders are not rate-limited. Nothing stops you sending them one after another — there is no cooldown and no record of when the last one went. Each one queues a notification and writes an audit record. Treat the restraint as yours to exercise, not the product's.

  • The gate you need is not offered on the action. Do not send an ad hoc request instead — it cannot satisfy a gate. Refresh the action, and if it is still missing, ask whoever manages the workflow to check its settings.

  • Everyone approved but the action is still blocked. The approved request does not match the action exactly. This usually means it was created separately rather than from the blocked action. Create a new request from the action itself.

  • Confirming your identity failed. Do not keep retrying and do not switch to a different sign-in method. Sort out your account or sign in again, then come back to the assignment.

  • Your assignment is no longer pending. Refresh. Someone else's rejection may have ended the request. Do not submit again.

  • An approval is not assigned to you but you are expected to decide it. You cannot. Ask the requester to send a request naming you.