> ## Documentation Index
> Fetch the complete documentation index at: https://docs.introw.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Projects

> Configure the MDF proposal form: CRM automations, partner attribution, multi-step approval, decision timeline, and off-portal submission channels.

export const Rail = ({children}) => <div className="not-prose" data-overview="rail">
    {children}
  </div>;

## Where it lives

Projects sits under **MDF**, at [Marketing Funds](https://app.introw.io/marketing-funds).

<Frame>
  <img src="https://assets.introw.io/docs/features/mdf/projects/shots/request.png" alt="A partner's fund request open for review, with what they plan to run, the amount asked for, the activity type and the thread the decision is made in." />
</Frame>

## Before you start

| You need                         | Why                             | Fix it                                                                                             |
| -------------------------------- | ------------------------------- | -------------------------------------------------------------------------------------------------- |
| A fund with an allocation        | A project spends against it     | [Set up a fund](/features/mdf/funds-allocation/guides/set-up-an-mdf-program)                       |
| Write access to MDF and forms    | The proposal is a form          | [Internal roles](/features/access/team-management/guides/create-an-internal-role)                  |
| Partner access to the experience | Partners submit from the portal | [Publish an experience](/features/portal/experiences/guides/build-and-publish-a-portal-experience) |

## How it works

A fund binds a **proposal form** (provisioned from a template, then yours to edit). When a partner submits it, Introw creates the project record - activity type, requested amount, activity date, expected outcomes - and attributes it to the submitting partner using your existing attribution method. The proposal opens as a collaborative project with a decision deadline, and once you set an approved amount it moves into the claim stage.

You can also run a **generic intake** that isn't bound to any fund. Such a proposal arrives in the MDF requests inbox with no fund; a room admin picks the marketing fund on it, which is what lets you accept it (acceptance then creates the approved, fund-linked project through the same automation). See [Generic intake and fund selection](#generic-intake-and-fund-selection) below.

You configure four things on the proposal form, all no-code:

```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart LR
  form["Proposal form"] --> mapping["CRM field mapping and attribution"]
  form --> approval["Agentic and human approval"]
  form --> timeline["Decision timeline"]
  form --> channels["Portal, link, embed, email, AI"]
```

## Settings & configuration

The proposal form is edited from the fund's lifecycle tabs (**Go to form** opens the form builder).

### The form and its fields

Add and arrange fields no-code. The template already captures the essentials (activity type, requested amount, activity date, expected outcomes); add your own for the data your program needs.

### CRM automations and attribution

On the form's automation, map each field to a CRM property (write a submitted value or a fixed value), and Introw attributes the created project to the partner using the method you configured on [Object Linking](/features/integrations/crm/attribution) - property, association, lookup, or relation table. No extra setup: the proposal is born attributed.

The project record itself is an Introw `MDF_REQUEST` object by default. If your team already tracks funding on a CRM object of its own, you can back `MDF_REQUEST` with that object so proposals land there instead - it then owns the schema, the properties, and the label Introw shows. See [Store MDF requests and claims in your CRM](/features/mdf/funds-allocation/guides/store-mdf-requests-and-claims-in-your-crm).

### Approval

Give the proposal its own approval flow: an **agentic (AI) review** that can auto-approve above a certainty threshold, and **sequential human approval steps** (each step a named approver, a partner-team role, or anyone) that must accept in order. Configure both on the form's approval settings.

### Decision timeline

Set the decision deadline on the fund's timeline (relative to the submission or activity date, or a fixed date), so a proposal never sits unanswered. Overdue proposals are flagged.

### Where partners propose

The proposal form is shareable by link, embeddable, submittable by email, and available to the partner's own AI assistant over MCP - each route lands the same attributed record.

### Generic intake and fund selection

When you have more than one fund, use a **generic intake** so partners never choose a budget:

* **The generic intake form** - enabling MDF provisions a fund-agnostic `MDF_REQUEST` form tagged **Generic**. It keeps type `MDF_REQUEST` (so submissions land in the MDF requests inbox and lifecycle) but is not any fund's proposal form, so its submissions carry no fund.
* **The experience-builder block** - in the portal/room editor's section picker, the **Marketing Funds** category offers a fund-agnostic **Request marketing funds** block alongside the per-fund blocks. It surfaces a Generic-tagged intake form and submits with no fund.
* **Pick the fund at review** - a generic request appears as a normal proposal in **Marketing Funds → Requests**. Opening it, a room admin picks the marketing fund from a dropdown. **Accept is disabled until a fund is picked** (Return, Decline, and collaboration stay available). Accepting then creates the approved, fund-linked project.
* **Change the fund from Edit** - a room admin can change the marketing fund from the request's **Edit** dialog, on the pending submission (updates the submission's fund) or on the accepted MDF request CRM object (cascades the new fund to its claims, ROI, and invoices). Room visitors never see this control.

## How-to guides

<Rail>
  * ![The proposal's no-code intake form is bound to the step; Go to form opens the builder.](https://assets.introw.io/docs/features/mdf/projects/guides/configure-the-proposal-form/steps/03.png)

    [**Configure the proposal step**](/features/mdf/projects/guides/configure-the-proposal-form)

    Configure the MDF proposal step: build the intake form, set CRM automations and partner attribution, approval gates, and the decision timeline.

  * ![A timeline sets the SLA to decide the request, so nothing sits unanswered.](https://assets.introw.io/docs/features/mdf/projects/guides/run-the-mdf-lifecycle/steps/05.png)

    [**Run the MDF lifecycle**](/features/mdf/projects/guides/run-the-mdf-lifecycle)

    Operate the full MDF lifecycle: configure the proposal, claim, ROI, and invoice steps, then review proposals, collect proof of spend, and mark projects paid.

  * [**Submit a proposal**](/features/mdf/projects/guides/submit-a-proposal)

    Every way a partner can propose an MDF activity - link, embed, email, Slack, Teams, AI assistant, or the API - all feeding the same proposal form, attributed.
</Rail>

## Troubleshooting

<Warning>
  Proposals use the standard form approval steps, configured in the form builder, not a separate MDF screen. Attribution follows your Object Linking configuration, so confirm that is set before you launch. The MDF module must be enabled on your plan.
</Warning>

<AccordionGroup>
  <Accordion title="A proposal is not attributed">
    Confirm the org's attribution method is configured on Object Linking.
  </Accordion>

  <Accordion title="A proposal will not move to claims">
    It needs an approved amount set first.
  </Accordion>

  <Accordion title="A partner cannot propose">
    Confirm their segment has an allocation and portal access.
  </Accordion>

  <Accordion title="Accept is disabled on a generic proposal">
    It has no fund yet. Pick a marketing fund on the request (the fund dropdown in the request view, or the Edit dialog) and Accept enables.
  </Accordion>

  <Accordion title="A generic request isn't in the requests inbox">
    Its form must be type `MDF_REQUEST`; that's what routes submissions into the MDF requests inbox.
  </Accordion>

  <Accordion title="The Request marketing funds block is empty">
    It needs a Generic-tagged `MDF_REQUEST` form. Enabling MDF provisions one automatically; you can tag another `MDF_REQUEST` form as Generic to offer more.
  </Accordion>

  <Accordion title="A room visitor can't change the fund">
    That's intentional. Only room admins can pick or change the marketing fund.
  </Accordion>
</AccordionGroup>
