Skip to main content

Intake workflows and funding policies

Setting up requests involves three components: templates, workflows, and funding policies. Templates define the forms requesters complete. Workflows define the states a request moves through after submission and who decides in each state. Funding policies determine who approves funding, based on the amount requested. You manage all three in Configuration, which you open from the app launcher.
​

Request templates

  1. Go to Configuration → Intake → Custom Templates

    The list has Active and Archived tabs. Each template shows its status (for example, Published), type (for example, Intake approval), where it's offered, its version, how many fields it has and its routing. Editing a published template creates a new version; requests already submitted keep the version they were submitted on.
    ​


    ​

  2. Select + New template to create one, or Edit → to open the template builder:

    1. Add a Name and Description

    2. Form fields: open a field (Edit) to set its type, choices, conditional display and whether it's required. Field types include Long text, Short text and Money. Select + Add field to add one.

    3. Requester preview: shows the form as requesters see it. Drag fields to reorder them, or delete them, here.

    4. Select Save to keep your changes, or Publish to make them available to requesters.
      ​

Approval workflows

  1. Go to Configuration → Intake → Workflows
    ​


    ​

  2. Select + New workflow to create one, or Edit on an existing workflow
    ​


    ​

  3. In the workflow builder, the canvas shows the states, such as Intake, Validation, Prioritization, Approval, Approved and Rejected, and the exits between them. Each state shows its type and who decides there, and each exit shows what it does: Moves forward, Sends back or Declines.
    ​


    ​

  4. Use + State to add a state, or select a state to edit it. Set its:

    1. Name and Type: Initial (the start; only one), Validation, Prioritization, Approval or Final (the end: Approved or Rejected);
      ​


      ​

    2. State Action Prompt: an action for the agent to take in that state. Select Test Action to try it;

    3. SLA (days): how long a request may sit in this state before whoever moves it on is notified it's past due. It's also flagged Past SLA on the Pipeline. Leave it empty for no SLA;

    4. Who decides here: People, Roles, Agent or Author or manager (no named approver: the request's author or a governance manager takes the exit). Add optional Instructions for the decider (What should the decider check?).

  5. Select an exit (the arrow between two states) to set its name and what it does: move the request forward, send it back to an earlier state, or decline it.
    ​

  6. Select Save to keep a draft, or Publish to make the workflow live.

Funding policy limits

  1. Go to Configuration → Funding Policies;
    ​


    ​

  2. The top section sets the most an approval by each role can cover. Each band shows a role, its band number and its maximum (for example ≤ $1,000,000, or ∞ for no limit), with its version. Limits are versioned and editable here. Select + Add band to add one.

Funding routing policies

The Routing section decides which approvers a funding request goes to, chosen by the amount being requested.

  • Routing policies · first match wins
    As the page explains, a funding request is matched against the policies in order, Space policies first, then org defaults, and the first match routes it. Each policy shows its name, whether it's an org policy, and its version.

  • Select a policy to edit it, or + New policy to create one. Saving shows exactly which request profiles change route before anything is committed.
    ​


    ​

  • History shows past versions:
    ​

Did this answer your question?