Workflows, Roles & Approval Filters
Three pieces decide how a submission is routed and who may act on it: the workflow (the ordered steps), the role each step names, and the approval filters that narrow which submissions a role member actually receives. This is the heart of FiscFlow's routing.
Workflows & steps
A workflow is an ordered list of approval steps. Each step names a role - never a specific person. A workflow is attached to a submission type, so every submission of that type follows the same path.
- A step names an approver role. The role picker only offers roles that are active and can approve submissions - a step can't route to a role that isn't allowed to approve.
- Steps run in order. New steps are added to the end automatically; the submission visits them lowest-order first.
- Routing is linear. There's no conditional branching - the submission moves one step at a time until every step has approved.
- A role can repeat. If the same role appears twice, the submission returns to it a second time and it must be approved again.
- The last step finalizes. Approving the final step marks the submission Approved.
Once a workflow has in-flight submissions (submitted but not yet finalized), FiscFlow blocks edits and deletion - "This workflow is in use by active submissions and cannot be modified." Let those submissions finish, or clone the workflow for future types.
Roles
A role is a set of capability switches, not a title with fixed powers. The switches that matter:
| Capability | What it grants |
|---|---|
| Can view work items | The master gate for seeing other people's submissions at all. Without it, no filters apply and the person sees nothing beyond their own. |
| Can approve submissions | May be named on a workflow step and approve/reject submissions. |
| Can approve employee assignments | May approve positions (see Assignment approval & lifecycle). This automatically implies "can view work items." |
| Can review employee assignments | May mark an assignment reviewed (a check that stops short of approval). |
How a person "gets" a role
You hold a role by having an employee assignment that carries it, on a personnel requisition in a given fiscal year. That's why role membership is always fiscal-year specific: an assignment (and its role) in last year's fiscal year does not let you act on this year's work.
No matter what filters say, an approver sees nothing unless their role has Can view work items and their user account is active. Filters only ever grant within the assignment's own fiscal year.
Which roles a non-administrator may hand out is also constrained: you can only assign roles that are "creatable from" a role you already hold in that fiscal year. Administrators bypass all of this and can see and do everything.
Approval filters
A workflow step says which role acts. Approval filters say which submissions a given role member receives. Filters hang off an approver's employee assignment, and each is either Allow or Deny.
The one rule to remember
A submission is visible/actionable to an approver when at least one Allow filter matches it, and no Deny filter matches it. Deny always wins over Allow - even a "match everything" Allow.
Two consequences worth internalizing:
- No filters means no access. An approver assignment with zero filters grants nothing. Access is opt-in - you must be granted by a matching Allow.
- A Deny is a surgical exclusion. Give a broad Allow, then carve out exceptions with Deny (e.g. Allow the whole site, Deny one sensitive account).
The dimensions a filter can match on
Each filter can pin any of nine dimensions. A dimension left blank is a wildcard - it matches anything. A filter with everything blank is a "match everything" filter.
| Dimension | Matches on |
|---|---|
| Account | The specific account. |
| Fund / Resource / Goal / Function / Object / Location | Any single segment of the account code - so you can scope by, say, a fund without naming exact accounts. |
| Classification | The position's classification. |
| Site | The site the submission is tied to. |
A Location filter also matches when the location is linked to the submission's site - not only when it's the account's own location. This lets a location-based approver reach work at their site even when the account's location differs. (This "via site" reach applies when matching the requisition's funding accounts; when a submission carries its own account, only that account's own location is compared.)
What the filter is compared against
FiscFlow figures out a submission's account(s) and site(s) based on its shape:
- Account: the submission's own account if it has one; otherwise the accounts on its personnel requisition.
- Sites: the submission's own site if it has one; otherwise the employee assignment's sites; otherwise the requisition's sites.
Filters are seeded automatically for approvers
When you save an approver assignment (a role with Can view work items) that has no filters yet, FiscFlow seeds one Allow filter per site on the assignment - a sensible default so the approver can immediately see their sites' work. If you hand-curate the filters, they are never overwritten; and if the role later loses Can view work items, its filters are removed.
Per-site scoping in practice
Because Site is a filter dimension, a single approver can be Allowed at one site and Denied at another on the very same multi-site position. They'll see and act on that position's submissions at the allowed site, and neither see nor act on them at the denied site. The full detail - including how hours entries are scoped per site - is on Who can see what.