Cross-module flows

What you will find here

Futuh’s modules do not work in isolation. A call for proposals that enters through Radar ends up in Gestión de ayudas to be formulated. A request that arrives through the Plataforma de Recepción Inteligente can become a simple task or, if the case calls for it, escalate to a project. Silvio cuts across all modules as a conversational layer. Federación Futuh feeds canonical data from a Hub Central that your organization does not have to maintain.

The individual pages for each module cover the detail of their own scope. This section brings together the cross-module flows: five canonical journeys that cover the most common work cycles for a third-sector organization using Futuh.

The five canonical flows

Flow	What it covers	When to read it
Capture and formulate a call for proposals	Call for proposals identified in Radar through to closure in Gestión de ayudas	When you want to understand the complete grant-work cycle in your organization
Process a document request	Request entering Plataforma de Recepción Inteligente through to becoming a task or project	When you collect documents from third parties and want the system to do the first triage
Converse with Silvio	Silvio as an action layer across all modules	When you want to understand what you can ask Silvio to do for each module without activating it separately
Synchronize with the Federation	Daily pull of canonical data from the Hub Central to your instance	When you are an administrator and need to configure the endpoint, see what comes from outside, and what is your own
Coordinate policy advocacy with data	Policy advocacy backed by impact data from the M&E module	When you combine policy advocacy work with quantitative justification for funders

Why canonical flows, not ad-hoc integrations

A characteristic of Futuh’s design is that modules connect through documented and stable stitching points, not through one-off integrations built for a single organization. When a call for proposals moves from Radar to Gestión de ayudas, it always does so with the same entry stage (Planning), carrying the same canonical fields (name, description, estimated requested amount, deadline, funder), and leaving a bidirectional link to the original call. When a request is validated by AI with high confidence, it is always done against the same administrator-configurable confidence threshold. When Silvio escalates a conversation, it always goes to the same native Discuss channel in Odoo.

This predictability matters for three reasons. First, team training is reduced: once a flow is learned, any team member recognizes it in any Futuh instance. Second, documentation is maintained once for everyone: these pages are equally valid for a development NGO with AECID funding and for a cultural federation with regional government funding. Third, product evolution does not break installations: when a new module appears (such as Datos M&E when it enters production), it is stitched into existing flows using the same pattern.

How the documented flows are chosen

The five flows you see here are the ones that appear again and again in pilot organizations of the product. They are not the only possible ones. An organization with a different profile (for example, a services cooperative with no public grant work) may never use the flow for capturing and formulating a call for proposals, but may use both the Silvio and document-request flows.

When a new flow stabilizes across enough production instances, it will be added here with its own page. There are three candidates foreseen for future versions: the complete cycle of intermediate justification with European funders, collection of activity evidence for annual reports, and the link between Radar alerts and follow-up alerts in Silvio.

How to read each flow

Each page in this section follows the same structure:

What it’s for: the flow described in one sentence.
Who is involved: roles and modules implicated.
Step-by-step journey: how the pieces link together, with [VERIFY:] where there is still open margin.
How this flow fits with the rest: table with the modules involved and a link to their detailed documentation.
Learn more: related reading.

You do not have to read the flows in order. Each one works as a standalone entry point. It is useful to have read Product map first if you are new to Futuh.

Learn more

Futuh product map to place the modules in context.
Glossary for the canonical terms that appear in each flow.
What is Futuh if you are just getting started.