Projects

A project represents a client engagement or initiative. It groups together the DRPs, requirements, and reference material for that piece of work, and controls who on your team can see and edit it.

Lead Analysts create projects. Each project has a name, a project code, and optional sponsor details.

Team members are added from the project's own Team tab. Only the people on a project's team can open its DRPs and requirements or change it — this keeps unrelated engagements separated within the same workspace. That includes Lead Analysts: they see every project in the Projects list, with its overview and team, but work only on the projects whose team they are on. Whoever creates a project joins its team automatically.

A project's team is changed by a Workspace Admin, or by a Lead Analyst who is already on that team. Nobody can add themselves to a project they are not on, so if you need access to a project, ask a Workspace Admin or one of its Lead Analysts.

Adding somebody asks which of their roles apply here. Your workspace roles say what you are ALLOWED to be; the roles chosen on a project say what you ARE, there. Somebody who is both an Analyst and a Reviewer can be added to one project as both, and to another as a Reviewer only — and on that second project they genuinely cannot write content, not merely have the buttons hidden.

• The picker offers every role that person holds at workspace level, and defaults to all of them.
• Workspace Admin never appears — it is not a project job.
• You can change the set later with "Edit roles" on the Team tab, without removing and re-adding the person — which would throw away their review assignments.
• A project role must be one they actually hold. Take a role away in the Users area and it comes off their projects too, retiring any review or approval slot that depended on it.

Archiving a project removes it from everyday lists without deleting its data — a Lead Analyst can restore it later from the "Archived Projects" tile on the dashboard, or by ticking "Show archived" on the Projects list itself.

Beyond the standard DRP module catalog, a Pro or Enterprise workspace can add its own modules to a project. From a project's Module Configuration section, click "+ Add module" to create one, give it a name, and it's ready to write into on any DRP in that project.

This self-serve option is a simple, free-text module — a blank writing area, added at no extra cost. AI suggestions still work for it: whatever you name the module is what the AI treats it as being about, so naming it clearly (e.g. "Vendor Risk Register" rather than leaving the default name) directly shapes the quality of what it drafts.

For a truly bespoke module — one with its own guided fields, tables, and AI drafting tailored to your organisation's exact process, built the same way as Requio's own structured modules — that's a made-to-order engagement rather than a self-serve toggle, at additional cost. Contact Sales to scope one out.

A project's Modules tab decides what every new DRP in that project starts with. It is open to Lead Analysts on the project's team, and nothing on it is saved until you press "Save configuration".

• Active — whether a module is included when a new DRP is created in this project. Turning it off keeps its reviewers, approver and default content, so you can turn it back on later, and never changes DRPs you have already created.
• Default content — what a new DRP starts with in that module. "Edit default" opens a box where you write it once — for example, a standard Introduction & Purpose paragraph your organisation uses on every pack. Leave it blank and every DRP starts that module empty.
• "Apply changes to existing DRPs (where compatible)" — tick it before saving if you also want the change to reach DRPs already created. Default content only ever goes into a module that is still Not started: if anyone has begun writing there, their work is left alone.

The same tab also holds the project's review settings — see the Review & Approval Workflow topic, "Where review settings are set".

A project's Branding tab sets how its generated documents look, so every pack from that project carries your organisation's identity rather than Requio's. It is open to Lead Analysts on the project's team.

• Logo — choose a PNG, JPG or GIF file. It appears at the top of each generated document.
• Header Font and Body Font — picked from a list of fonts that display reliably in Word. Leave either on "Default (Calibri)" if you have no house style.
• Brand Colors — Primary, Secondary and Accent, used for headings, borders and highlights.

A small preview card beside the settings shows the logo, fonts and colours together as you change them. Press "Save Branding" to keep them. The branding is used in the generated .docx, in the DRP's "Preview latest version" window, and on the page people see when you share a version.