This is the full developer documentation for NGOstack # Documentation > Select your role. The switcher at the top follows that selection. For members Participation: profiles, finding and posting opportunities, connecting with other members, and collaborating in workspaces. [Start here](/start/) · [What your plan includes](/start/plans/) · [Post an opportunity](/opportunities/post/) For organisations Running programmes: projects, results planning, updates and evidence, and working with partner organisations. [Set up an organisation](/organization/) · [Project or workspace?](/projects/vs-workspaces/) For developers Building on the platform: the REST API, the MCP server for AI agents, and error reporting. [Overview](/developers/) · [API reference](/developers/api/) · [MCP server](/developers/mcp/) API reference Every documented endpoint, generated from the platform’s own OpenAPI description: shapes, parameters and status codes as implemented by the server. [Open the reference](/developers/api/) · [Authentication](/developers/authentication/) Help & FAQ Questions answered before signing up: cost, data handling, and visibility. Maintained in the product rather than on this site. [Help & FAQ](https://ngostack.org/help) · [Support](https://ngostack.org/support) Community Discussion, events and peer support are hosted in the community space, which runs on **Mighty Networks**, a separate product with its own documentation. [Open the community](https://community.actionnetwork.world) · [Mighty Networks help](https://docs.mightynetworks.com/) Machine-readable formats Every page is available as Markdown by appending `.md` to its URL. The index is at [`/llms.txt`](/llms.txt), the full corpus at [`/llms-full.txt`](/llms-full.txt), and per-audience sets are under `/_llms-txt/`. # For developers > Build on the platform — REST API, MCP server and integrations. The platform exposes two programmatic surfaces: | Surface | Base URL | Shape | | -------------- | ---------------------------------------- | ------------------------------------ | | **REST API** | `https://api.actionnetwork.world` | OpenAPI 3, JSON over HTTPS | | **MCP server** | `https://api.actionnetwork.world/v1/mcp` | Model Context Protocol, OAuth-scoped | Refer to the [API reference](/developers/api/) for the REST surface, or the [MCP server reference](/developers/mcp/) when connecting an AI agent. ## Documentation for agents [Section titled “Documentation for agents”](#documentation-for-agents) This site publishes the conventions agents expect: * [`/llms.txt`](/llms.txt) — the page index * [`/llms-full.txt`](/llms-full.txt) — every page as one document * Any page as Markdown by appending `.md` to its URL ## What the API reference covers [Section titled “What the API reference covers”](#what-the-api-reference-covers) **The reference covers the integrable surface, not the whole API.** The platform’s OpenAPI description covers several hundred paths, as it describes the interface used by the portal, desktop and mobile applications. The reference publishes the portion available to an integrator: **member data read with an access token** — the wikis, workspaces and projects the member belongs to. Which endpoints a token may reach is not determined here. It is read directly from the API’s own access table, so the reference tracks the platform rather than restating it. Two endpoints require no token, as they are read *before* one is held: the OAuth resource metadata an MCP client retrieves to locate the authorisation server, and `/v1/whoami`, which reports whether a supplied token is valid and what it can reach. The `/v1/public/**` endpoints are not documented here The platform serves its own public pages — the atlas, organisation pages, the blog and the public knowledge base — from endpoints requiring no credentials. These remain reachable, but they exist to serve those pages rather than as an integration surface: no compatibility guarantee is offered, and their shapes change with the pages they support. They are omitted deliberately rather than documented for a use they are not designed for. **Every endpoint in the reference is a `GET`.** This is not an omission; it is the full extent of the REST surface available to an external client. A token is read-only over REST and no scope alters this, so every non-`GET` request is refused. **Writes are performed over MCP**, where approximately half the tools are mutating. Documentation for creating a page or moving a task is in the [MCP server reference](/developers/mcp/) rather than here. ## What the reference does not report [Section titled “What the reference does not report”](#what-the-reference-does-not-report) **Plan gates.** Several capabilities require Solo or Org. An endpoint not included in the current plan returns `403`, although the reference presents it as available. The plan required for each capability is listed in [what your plan includes](/start/plans/). **Token narrowing.** The reference states which *scope* an endpoint requires. It cannot report whether a particular token was additionally narrowed to specific organisations, workspaces or spaces. A call within the token’s scopes may still be refused because the resource falls outside its resource filter — see [what an external client can reach](/developers/access/). A `403` should therefore be read as a plan or token restriction rather than as a malformed request. ## Errors [Section titled “Errors”](#errors) Every failure returns the same envelope and carries a **ticket ID**, which allows a support request to be resolved without reconstructing the failure. → [Errors](/developers/errors/) # What an external client can reach > Tokens are read-only over REST and can write over MCP; an unnarrowed token has broad reach. An access token behaves **differently on the two surfaces**. This distinction should be understood before a token is granted. ## Over REST, a token is read-only [Section titled “Over REST, a token is read-only”](#over-rest-a-token-is-read-only) Every non-`GET` request made with an access token is refused: ```json { "error": "Forbidden", "message": "Access tokens are read-only. Use your account credentials for write operations." } ``` This is a blanket rule rather than a scope check: no scope permits a token to `POST` over REST. Writing through the REST API requires account credentials. ## Over MCP, a token can write [Section titled “Over MCP, a token can write”](#over-mcp-a-token-can-write) Writes are performed over the MCP surface. Of the tools currently published, **approximately half are mutating**: creating and deleting wiki pages, rows and comments, and creating, updating and archiving workspace deliverables. These writes are deliberately not gated by an administrative role. Editing a page in one’s own space or moving a task in a workspace one belongs to are ordinary member actions. They are constrained **at the point of use** by membership, plan, and the same role and mode checks the REST routes apply. **A tool outside the token’s scopes is not listed.** It is not presented and then refused; the agent does not see it. An agent’s apparent capabilities therefore correspond exactly to its token’s scopes. ## What each permission grants [Section titled “What each permission grants”](#what-each-permission-grants) The token dialog states the reach of each permission:  Creating a token — scopes, and narrowing what it can reach[Open `/a/settings/integrations` in the app](https://ngostack.org/a/settings/integrations) | Permission | Reaches | | --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | **Read wikis** | Pages, databases and rows in your personal wiki, the wikis of organisations you belong to, and the wikis of workspaces you belong to | | **Read workspaces** | Members, tasks, activity and health of workspaces you belong to — **and only those whose coordinator has switched on external agent access** | | **Read knowledge base** | Published knowledge-base entries. Reaches no workspace, project or wiki | | **Read projects & reports** | Projects you are a member of, **including budgets, expenses, impact evidence and full grant reports** | **Read projects warrants the most consideration.** It does not return a list of project names alone; it includes financial records and impact evidence. An agent granted it can read recorded expenditure and reported outcomes. Write access is in a separate section of the same dialog, collapsed by default. Read and write are independent: a write permission does **not** imply the corresponding read. **Every token requires an expiry date.** The field is mandatory; permanent tokens are not available. ## The reach of an unnarrowed token [Section titled “The reach of an unnarrowed token”](#the-reach-of-an-unnarrowed-token) A token may be narrowed on four dimensions, which **intersect** rather than combine: | Dimension | Limits | | ----------------- | -------------------------------------------------------------- | | `workspaceIds` | Workspace deliverables, and workspace-owned wiki spaces | | `orgIds` | Org-owned wiki spaces, and projects (which are org-scoped) | | `spaceOwnerTypes` | Which *types* of space are reachable: personal, org, workspace | | `spaceIds` | Individual spaces; the finest granularity | Each accepts up to 50 entries. Absence means unrestricted, not denied Omitting a dimension does not restrict it; it leaves it open. A `spaces:read` token created without a resource filter reaches **the personal wiki and every organisation wiki of every organisation the member belongs to**. This default is deliberate, so that adding new dimensions never silently reduces an existing token’s reach. It also means a token is restricted only where it has been narrowed explicitly. `{ spaceOwnerTypes: ['user'] }` restricts the token to the personal wiki. `{ orgIds: [A] }` excludes organisation B’s wiki and B’s project finances. `{ orgIds: [A], spaceIds: [S] }` denotes space S, and only if it belongs to organisation A — an intersection rather than a union. ## Workspace spaces carry a second control [Section titled “Workspace spaces carry a second control”](#workspace-spaces-carry-a-second-control) **Workspace-owned spaces** are additionally subject to the workspace coordinator’s external-access setting, so a coordinator can exclude external agents from a shared space regardless of any member’s token. **Personal and organisation spaces have no equivalent per-space control.** Narrowing the token is the only available restriction, which is the purpose of `spaceOwnerTypes` and `spaceIds`. [Access tokens](https://ngostack.org/a/settings/integrations)Settings → Integrations # Authentication > Two ways in — a token you mint yourself, and OAuth discovery for MCP clients. Two authentication methods are available. The appropriate one depends on the client being built. ## Access tokens [Section titled “Access tokens”](#access-tokens) For scripts and self-hosted services. Create a token under **Settings → Integrations**, grant the narrowest permissions sufficient for the task, and send it as a bearer token. **The token is displayed once.** Only a hash is stored, together with an eight-character prefix for identification in the list. A lost token must be replaced. **Tokens expire.** An expiry date is required at creation; permanent tokens are not available. Note the asymmetry: over REST a token is **read-only**, and every non-`GET` request is refused. See [what an external client can reach](/developers/access/). ## OAuth, for MCP clients [Section titled “OAuth, for MCP clients”](#oauth-for-mcp-clients) An AI agent does not use a manually supplied token; it discovers the authentication endpoint. The flow follows the MCP authorization spec, which builds on **RFC 9728 protected resource metadata**: 1. The client calls the MCP endpoint with no credential and receives **401**. 2. The response points it at a metadata document describing where to authenticate. 3. The client reads that document, runs the OAuth flow against the authorisation server it names, and retries with the token it obtains. Two discovery paths are served, because clients probe both forms: | | | | ---------------------------------------------- | -------------------------------- | | `/.well-known/oauth-protected-resource` | Origin-wide | | `/.well-known/oauth-protected-resource/v1/mcp` | Path-suffixed, per RFC 9728 §3.1 | Both are **unauthenticated by design**: the client holds no credential at that stage, which is the purpose of the document. The metadata must be reachable and correct, or the client fails silently A client that cannot retrieve this document, or that finds within it a URL not matching the resource it called, discards the document per the specification and fails to connect. No error is produced on either side. Where an agent fails to connect and nothing is logged, retrieve these two URLs directly and verify the origin they advertise. [Access tokens](https://ngostack.org/a/settings/integrations)Settings → Integrations # Errors > The error envelope, what each status code means, and the ticket ID that makes support fast. Every error response has the same shape, whatever produced it: ```json { "message": "Route GET:/v1/does-not-exist not found", "error": "Not Found", "statusCode": 404, "ticketId": "fd7c6076-29ac-4b25-94e0-6b74be6bb955" } ``` | Field | Use it for | | ------------ | ------------------------------------------------------------------------------------ | | `message` | A human-readable description. **Do not parse it**; the wording is subject to change. | | `error` | The status text. Redundant with `statusCode`, and present for readability. | | `statusCode` | The HTTP status, repeated in the body so that a logged payload is self-contained. | | `ticketId` | A unique identifier for this specific failure. See below. | Branch on `statusCode`, never on `message`. ## The ticket ID [Section titled “The ticket ID”](#the-ticket-id) Every error carries a `ticketId`. The same identifier is recorded server-side together with the full context of the failure. **Include it in any support request.** A request quoting a ticket ID can be looked up directly; one without requires the failure to be reconstructed from a description and a timestamp. When logging error responses, log the complete envelope rather than the message alone. The ticket ID is the field of lasting value. ## Status codes [Section titled “Status codes”](#status-codes) | Code | Means | Retry? | | ----- | -------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------- | | `400` | The request body or query failed validation. | No; correct the request. | | `401` | Missing, malformed or expired credentials. | After refreshing the token. | | `403` | Authenticated but not permitted: an insufficient role, or a scope not granted. | No. | | `404` | No such route, or no such record *visible to the caller*. | No. | | `409` | Conflict with the current state. | Only after re-reading the resource. | | `429` | Rate limited. Rate limit headers are returned on every response: `x-ratelimit-limit`, `x-ratelimit-remaining` and `x-ratelimit-reset`. | Yes, after `x-ratelimit-reset`. | | `5xx` | A server-side failure. | Yes, with backoff. Retain the ticket ID. | ## Rate limits [Section titled “Rate limits”](#rate-limits) Rate limit headers are on **every** response, not just a `429`: | Header | | | ----------------------- | ------------------------- | | `x-ratelimit-limit` | The budget for this route | | `x-ratelimit-remaining` | What is left of it | | `x-ratelimit-reset` | When it refills | **The budget is per route, not per account.** Most routes carry their own allowance, commonly ten, twenty or thirty requests per minute. A few are substantially tighter where abuse is a concern: sign-in is ten per minute, AI endpoints ten per minute, and account deletion twice per day. Read `x-ratelimit-limit` from the response to the request being made rather than assuming a global figure. The limit on one endpoint does not indicate the limit on another. On `429`, wait until `x-ratelimit-reset` before retrying. Retrying within a closed window consumes the subsequent one. ## Two commonly misread codes [Section titled “Two commonly misread codes”](#two-commonly-misread-codes) **`404` does not always indicate non-existence.** Where a response of “exists but is not accessible” would itself disclose information, the API returns `404` rather than `403`. An inaccessible record and a non-existent one are indistinguishable externally. A `404` is therefore not evidence that an identifier is available for reuse. **`403` concerns authorisation, not authentication.** Where a `403` is returned on a route expected to be accessible, check the **scopes** granted to the token before checking the member’s role: a missing scope and a missing role produce the same status. See [the MCP scope table](/developers/mcp/). # MCP server > Connect an AI agent over the Model Context Protocol. The platform exposes an MCP server so agents can read and write workspace and wiki data on a member’s behalf. **Endpoint:** `{tools.endpoint}` (Streamable HTTP) ## Scopes determine which tools exist [Section titled “Scopes determine which tools exist”](#scopes-determine-which-tools-exist) This is the most consequential behaviour to understand before integrating, and it is not apparent from a `tools/list` call. Tools are registered **conditionally on the scopes in the grant**. A tool not covered by the token is not returned as forbidden; it is not registered, and therefore does not appear in the tool list. An agent holding only `workspaces:read` is presented with three tools and no indication that others exist. `tools/list` therefore returns the subset available to the caller, not the catalogue. The full catalogue follows. Where this table comes from Generated from the platform’s own tool registration, so the tools and scopes below are the ones the server actually publishes rather than a hand-kept list. Last generated 2026-09-06. ## Tool catalogue [Section titled “Tool catalogue”](#tool-catalogue) | Tool | Required scope | Description | | ------------------------------- | ------------------ | ---------------------------------------------------------------------------------------- | | `archive_workspace_deliverable` | `workspaces:write` | Archive a deliverable — hides it from the default task list without deleting it. | | `create_wiki_comment` | `spaces:write` | Post a comment on a wiki page, or reply to an existing thread by passing its root | | `create_wiki_page` | `spaces:write` | Create a wiki page. \`content\` is a ProseMirror/TipTap document object; omit it to | | `create_wiki_row` | `spaces:write` | Create a row in a wiki database. \`data\` is keyed by COLUMN ID (not column name) — | | `create_wiki_rows` | `spaces:write` | Create MANY rows in a wiki database in a single call — use this instead of repeated | | `create_workspace_deliverable` | `workspaces:write` | Create a deliverable (a task) in a workspace. Assignees must be members of that | | `delete_wiki_page` | `spaces:write` | Move a wiki page to the trash. This also trashes all of its descendant pages. | | `delete_wiki_row` | `spaces:write` | Delete a row from a wiki database. Soft delete — the row is removed from all reads | | `delete_wiki_rows` | `spaces:write` | Delete MANY rows from a wiki database in a single call — the counterpart to | | `get_deliverable_progress` | `workspaces:read` | Get a progress breakdown of all deliverables in a workspace, grouped by status | | `get_or_create_wiki_row_page` | `spaces:write` | Get the wiki page attached to a database row, creating it on first call. A row holds | | `get_wiki_database` | `spaces:read` | Get a wiki database schema (columns + views) plus a PAGE of its rows. Rows are capped | | `get_wiki_page_backlinks` | `spaces:read` | Find what references a wiki page: other pages linking to it, database rows whose | | `get_wiki_page_comments` | `spaces:read` | Read the comment threads on a wiki page: each root with its replies, who wrote them, | | `get_wiki_page_history` | `spaces:read` | List a page's saved versions, newest first — id, title, optional label and when. | | `get_workspace_summary` | `workspaces:read` | Get a combined summary of a workspace: details, health metrics, and role breakdown | | `resolve_wiki_comment` | `spaces:write` | Mark a comment thread resolved, or reopen it. Only a ROOT comment can be resolved — | | `restore_wiki_page_version` | `spaces:write` | Restore a page to one of its saved versions, listed by get\_wiki\_page\_history. This is | | `search_wiki` | `spaces:read` | Search wiki page titles/content and database rows across your accessible spaces | | `search_workspaces` | `workspaces:read` | Search accessible workspaces by title or filter by status/mode | | `set_wiki_row_relation` | `spaces:write` | Set which rows of another database a row links to, through a DB↔DB relation column. | | `update_wiki_page` | `spaces:write` | Update a wiki page. Only the fields you pass are changed. Content edits are | | `update_wiki_row` | `spaces:write` | Update cells of a wiki database row. This is a PARTIAL patch — only the column ids | | `update_workspace_deliverable` | `workspaces:write` | Update a deliverable. Pass \`status\` to move it through the workflow (this is the | ## Scope summary [Section titled “Scope summary”](#scope-summary) | Scope | Grants | | ------------------ | --------------------------------------------------- | | `workspaces:read` | Workspace resources and search | | `workspaces:write` | Creating and updating deliverables | | `spaces:read` | Wiki spaces, pages and databases | | `spaces:write` | Creating and updating wiki pages, rows and comments | Read scopes are additive and independent; a write scope does not imply its read scope, so request both. ## Writing to wiki databases [Section titled “Writing to wiki databases”](#writing-to-wiki-databases) Row data is keyed by **column ID, not column name**. Read the schema with `get_wiki_database` first. When adding more than a couple of rows use `create_wiki_rows` to send up to 50 at once — the endpoint is rate limited per minute, and batching is the difference between an import that completes and one that is throttled part-way. Database and column *structure* cannot be changed through MCP: no create, alter or drop of databases, columns or views. # Webhooks > Outbound project events, three independent security layers, and why a failed delivery is silent. Outbound webhooks are Org plan. An organisation registers endpoint URLs, and the platform `POST`s JSON to them over HTTPS when something happens. ## The events [Section titled “The events”](#the-events) Five events are currently emitted, all project-scoped: | Event | Fires when | | --------------------------- | -------------------------- | | `project.update.published` | An update is published | | `project.evidence.created` | Evidence is recorded | | `project.evidence.updated` | An evidence record changes | | `project.evidence.deleted` | Evidence is removed | | `project.milestone.reached` | A milestone is completed | ## Security layers [Section titled “Security layers”](#security-layers) An unprotected endpoint is a URL receiving JSON. Three independent layers may be applied, and they combine. Only the first is enabled by default. **HMAC signing** — enabled by default. Adds an `X-ANW-Signature` header. The secret is generated and **returned once** at creation; it must be stored at that point, or signing disabled and reconfigured. Verify the signature rather than relying on the source address. **Custom headers** — static headers required by the receiver, most commonly an `Authorization` header. Values are **encrypted at rest and never returned**, so they cannot be retrieved from the platform. **Custom body parameters** — static fields merged into the payload root, for receivers expecting a token in the body rather than a header. Handled identically: encrypted, and never returned. ## Delivery and failure handling [Section titled “Delivery and failure handling”](#delivery-and-failure-handling)  Outbound webhook endpoints, with their signing and delivery state[Open `/a/settings/integrations` in the app](https://ngostack.org/a/settings/integrations) Dispatch is **fire-and-forget**: it does not block, and does not fail the action that triggered it. Publishing an update succeeds regardless of whether the endpoint responded, so a receiver outage does not affect platform users. Failures are not notified, but they are recorded. The endpoint list reports each endpoint’s **status** and **last delivery**. The information must be checked; it is not pushed. **Repeated failures automatically disable the endpoint.** A receiver that is unavailable for a sustained period ceases to be called, and re-enabling it is a manual action. Check the status column following any outage on the receiving side. **An organisation can register up to ten endpoints.** **Send a test ping before relying on an endpoint.** It is the least costly way to detect an incorrect URL, header or signature check. The screen also includes a **“How to verify deliveries”** section for the implementer of the receiver. [Webhooks](https://ngostack.org/a/settings/integrations)Settings → Integrations # Funder intelligence briefs > What the platform works out about a funding call before you spend a week on it — and the pipeline it feeds. Funder intelligence needs Org plan. A **brief** is the platform’s analysis of a single funding opportunity in relation to your organisation. It is intended to answer, without requiring a full reading of the guidelines, whether the opportunity merits the effort of an application. ## What a brief contains [Section titled “What a brief contains”](#what-a-brief-contains) Five sections, each addressing a different question: | Section | Answers | | ----------------------- | ------------------------------------------------------------------------------ | | **Eligibility check** | Whether the organisation is eligible, and where the guidelines are silent | | **Funder DNA** | What the funder has funded in practice, as distinct from its stated priorities | | **Competitive reality** | The likely applicant field | | **Strategic angle** | The framing most likely to succeed with this funder | | **Red flags** | Factors that would make an application unproductive | Each brief also carries a **verdict**, a **score** and the **deadline**, which is what the list is sorted and filtered on. **Read the red flags first.** The section exists because the costlier error is not an unsuccessful application but a substantial effort spent on one for which the organisation was never eligible. ## Briefs are generated analysis [Section titled “Briefs are generated analysis”](#briefs-are-generated-analysis) A brief is generated from the call, the organisation profile and known information about the funder. It can be incorrect, particularly where the funder’s guidelines are imprecise. Two mechanisms address this: **Community notes.** A brief can be annotated by category for the benefit of subsequent applicants. Information learned during an application that the guidelines did not state belongs here. **Corrections.** Where the analysis is incorrect, submit a correction rather than working around it. **Regenerate** re-runs the analysis. This is appropriate when the call has been updated or the organisation profile has changed substantially, as the brief is written against both. ## Decisions and the pipeline [Section titled “Decisions and the pipeline”](#decisions-and-the-pipeline) Every brief carries a decision, and there are only three states: | Decision | Means | | --------------- | ------------------------------ | | **Unset** | Not yet assessed — the default | | **Shortlisted** | Intended for pursuit | | **Dismissed** | Assessed and declined | **Dismissal is a recorded decision and should be used.** An unset brief and a dismissed one are indistinguishable in a total but represent opposite states: one is a decision, the other is an outstanding item. Shortlisting also moves a brief into the fundraising pipeline shown at the top of the page: **Analysed → Shortlisted → Drafting → Submitted → Won / Lost**  The fundraising pipeline — briefs and proposals counted by stage[Open `/a/briefs` in the app](https://ngostack.org/a/briefs) The first two stages are brief states; the remainder derive from the [proposals](/funding/proposals/) written against them. Win rate and conversion are computed from the same chain, and are therefore only as accurate as the recorded outcomes. [Funder intelligence](https://ngostack.org/a/briefs)Funding → Briefs # The proposal engine > Generating a first draft from your organisation's own material, and tracking what happened to it. The proposal engine needs Org plan. A proposal is drafted **from the organisation’s profile and its projects**, against a specific call. The engine addresses the initial drafting stage rather than the submission: its output is a first draft for revision, not a finished application. ## Starting a proposal [Section titled “Starting a proposal”](#starting-a-proposal) **New proposal** opens a four-step wizard — **Mode → Format → Context → Review** — rather than a blank document.  Step one — how you want the AI to work with you[Open `/a/proposals/new` in the app](https://ngostack.org/a/proposals/new) ### Step 1 — mode [Section titled “Step 1 — mode”](#step-1--mode) Both modes generate a first draft. They differ in what follows: | Mode | What it does | Suits | | ------------------------ | ------------------------------------------------------------- | ----------------------------------------------------------------------- | | **Full AI generation** | Produces a complete draft, opened in review mode for revision | A known funder, a short deadline, or iteration by editing | | **Step-by-step builder** | Produces a skeleton, then proceeds section by section | A new funder, complex scope, or where section-level control is required | The builder is appropriate where the funder’s expectations are not yet established. Full generation is appropriate where they are, and revision is faster than specification. ### Step 2 — format [Section titled “Step 2 — format”](#step-2--format) Six formats, which are not interchangeable: | Format | What it is | | -------------------------------- | ------------------------------------------------------------------------------------- | | **Outreach letter** | Initial approach to a funder. Short, relationship-building, **containing no request** | | **Letter of Intent (LOI)** | Semi-formal signal you intend to apply. Usually a paragraph or two | | **Expression of Interest (EOI)** | Preliminary response to a call. Lighter than a concept note | | **Concept note** | A 4–8 section brief. The first formal submission, once the funder shows interest | | **Full proposal** | The complete submission — workplan, budget, logframe and risk. Sent on invitation | | **Revision response** | A reply to a funder who asked for changes | Selecting the wrong format is readily apparent to a reader: an outreach letter opening with a request, or a concept note written at full-proposal length, both indicate the guidelines were not followed. ### Step 3 — context [Section titled “Step 3 — context”](#step-3--context) This step determines the register of the draft, and records four attributes: | | | | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Relationship** | Cold, warm, or post-meeting. A first approach differs from a follow-up | | **Formality** | Formal, semi-formal or conversational | | **Funder type** | Foundation, government, bilateral, multilateral, corporate, UN agency, EC programme, trust, or other | | **Funder archetype** | EU Institutional, Nordic Bilateral, Anglophone Foundation, US Foundation, UN Agency, Francophone Bilateral, German Bilateral, Community Foundation, Crowdfunding Narrative | **The archetype is the most consequential of the four.** Funding traditions differ in what they require and in what order. An EU institutional application and a US foundation letter are structurally different documents rather than variants of one, so the archetype determines more than formatting. A free-text field for **additional context** records anything the structured fields cannot express: a prior conversation, a named programme officer, or a known constraint. ### Step 4 — review [Section titled “Step 4 — review”](#step-4--review) A final review before generation. Nothing is written until the wizard is completed. ### Starting from an existing record [Section titled “Starting from an existing record”](#starting-from-an-existing-record) The wizard accepts an **opportunity** or a **brief** as its starting point, so a proposal can begin from a call already identified or from [funder intelligence](/funding/briefs/) already generated. Two properties of the wizard: **Each step requires a selection.** Continue remains disabled until one is made, so a decision cannot be deferred. **Save & exit is available.** A partially completed wizard can be resumed, which is relevant at the Context step where required information may not be immediately available. ## Status and outcome are separate fields [Section titled “Status and outcome are separate fields”](#status-and-outcome-are-separate-fields) Most comparable tools combine the two, which is a common source of confusion. **Status** records the state of the document: `draft` or `submitted`. **Outcome** records the result: `pending`, `funded`, `declined` or `withdrawn`. A submitted proposal remains `pending` until an outcome is recorded. A proposal may therefore be submitted and pending for an extended period, which is the normal case. The two fields record different facts. Both are set on the draft after the event: marking a proposal submitted records the submission date, and the outcome is recorded when the funder responds. Drafts can be **deleted in bulk**. **Recording outcomes is frequently omitted and is required for reporting.** Win rate and conversion on the [funder intelligence](/funding/briefs/) pipeline are computed from these outcomes. Proposals left as `pending` produce no figures. [Proposals](https://ngostack.org/a/proposals)Funding → Proposals # Finding and connecting with people > Browsing members, sending and answering connection requests, and suggested connections. The network has three parts: **Members** for finding people, **Connections** for managing existing connections, and **Matches** for platform suggestions. ## Finding people [Section titled “Finding people”](#finding-people) **Network → Members** lists every active member, and each person has a profile page showing a fixed set of fields: name, bio, specialty, intent, interests, match tags, country, the organisations they belong to, and — where one exists — your match score and connection status with them. **The field set is identical for every signed-in viewer.** No filtering is applied per viewer, so a sparse profile indicates incomplete information rather than restricted visibility. Account settings are not included: no email address, and no notification or billing detail. The visibility switch is about the public web, not about other members Settings → Profile → **Visibility** carries one switch, *Show my profile publicly*. It governs your logged-out profile page and whether you appear in the public member directory and map. It does **not** change what other signed-in members see — they get the fields above either way, and you still appear in Network → Members. Signing in is what gets you that view. To withhold information from other members, leave the field empty; the switch does not achieve this. ## Connection requests [Section titled “Connection requests”](#connection-requests) Connecting is bilateral: a request is sent, and the recipient accepts or declines. A connection has **four** states, on which the Connections screen filters: Pending, Accepted, Declined and Completed.  The Connections list filters by state — All, Pending, Accepted, Completed.[Open `/a/network/connections` in the app](https://ngostack.org/a/network/connections) | State | What you can do | | ----------------------------- | ------------------------------------------------------ | | **Pending** — sent by you | Withdraw, until answered. Available to the sender only | | **Pending** — received by you | Accept or decline | | **Accepted** | Collaborate; either party may later mark it Completed | | **Completed** | Closed, with an outcome recorded. See below | **Declining notifies the sender.** The action is not silent. **Withdrawal is possible only while a request is pending**, and only by the sender. A request that has been accepted or completed cannot be withdrawn. Requests can be accepted or declined **in bulk** from the list. ### Completing a connection [Section titled “Completing a connection”](#completing-a-connection) Accepted is not the end state. Either participant — not just the person who received the request — can mark a connection **Completed**, and completing it records: | | | | ------------ | -------------------------------------------------------------------------- | | **Outcome** | One of: collaborated, opportunity, knowledge exchange, or simply connected | | **Feedback** | Up to 500 characters, optional | Completion is frequently omitted, and it is what distinguishes a connection that produced a collaboration from one that produced a conversation. Only completion records that distinction. Note the asymmetry: acceptance is available to the recipient alone, whereas **completion is available to either party**. ### Where a connection came from [Section titled “Where a connection came from”](#where-a-connection-came-from) The Connections list includes an **Origin** column, as a request can arrive by four routes: `direct`, `browse`, `match`, or `opportunity`. The last indicates a connection made in relation to a specific listing. That route changes one rule: normally only **one** connection may exist between two members, but an opportunity connection is scoped to its opportunity. The same two members can therefore connect again in relation to a different listing without removing the first. Notifications for all of this are controlled under [Notifications](/settings/notifications/) — **Connection alerts**. ## Suggested connections [Section titled “Suggested connections”](#suggested-connections) **Network → Matches** suggests members based on shared areas of work. It requires Solo plan. Each suggestion carries a **relevance score**. Weak matches are excluded rather than ranked low, so the list is short by design and contains only suggestions above the threshold. Note Connection matching and *opportunity* matching are separate systems sharing a term. This page covers member matching; opportunity matching is documented separately. [Connections](https://ngostack.org/a/network/connections)Network → Connections [Members](https://ngostack.org/a/network/members)Network → Members # How matching works > What produces a match, why breadth in your profile hurts, and how to improve yours. Matching needs Solo plan. The platform suggests people, organisations and opportunities by comparing your profile against theirs. This page documents what is compared, which determines how a profile should be completed. ## Match explanations [Section titled “Match explanations”](#match-explanations) Each match carries a score, a breakdown of its components, and a list of **signals** stating the specific reasons in plain terms — for example, “You share four interests”. Where a match appears incorrect, the signals identify the profile field that produced it.  The prompt the product shows when matching has little to work with[Open `/a/network/matches` in the app](https://ngostack.org/a/network/matches) ## What the score is made of [Section titled “What the score is made of”](#what-the-score-is-made-of) Four parts, weighted: | Part | Weight | What it measures | | ------------------ | ----------- | -------------------------------------------------------------------- | | **Overlap** | 60% | Shared terms across interests, match tags, focus areas and specialty | | **Meaning** | 30% | Semantic similarity of your written text | | **Distance** | 10% | How close you are geographically | | **Prior outcomes** | up to +0.15 | Connections with this person that you actually completed | The first three form a weighted blend summing to 1.0. The fourth is **added to that total**, which is then capped at 1.0. **Concrete overlap carries the greatest weight by design.** It is explainable, stable over time, and more readily verified than a similarity judgement. ### Field weights within overlap [Section titled “Field weights within overlap”](#field-weights-within-overlap) Overlap is itself a weighted average, and the fields do not weigh equally: | Field | Weight | Applies to | | --------------- | ------ | ------------------------ | | **Interests** | 3 | People | | **Match tags** | 2 | People and organisations | | **Focus areas** | 2 | Organisations | | **Specialty** | 1 | People | **A field is scored only where both parties have completed it.** If one party has a specialty and the other does not, specialty is excluded from the average rather than scored as zero. An empty field therefore does not reduce the score; it removes a route by which the member can be found. The consequence: two well-suited members who have each completed only one field, and a different one, score zero against each other. Breadth across *fields* is beneficial, whereas breadth *within* a field is not. ### Completed connections raise future matches [Section titled “Completed connections raise future matches”](#completed-connections-raise-future-matches) The bonus comes from [connections you marked completed](/network/connect/), and how much depends on the outcome you recorded: | Outcome | Bonus | | ------------------ | ----- | | Collaborated | +0.15 | | Opportunity | +0.12 | | Knowledge exchange | +0.10 | | Connected | +0.05 | The bonus is added rather than weighted because the other three components *predict* a match while a recorded outcome *confirms* one. Confirmation is evidence of a different kind and therefore raises the score rather than competing for a share of it. In practice, completing connections is the one matching input determined by recorded activity rather than by profile content. ## Breadth dilutes overlap [Section titled “Breadth dilutes overlap”](#breadth-dilutes-overlap) Overlap is scored as **shared terms divided by combined terms**, not by the absolute number shared. Two members each listing five interests and sharing three produce a strong match. Two members sharing the same three from lists of fifty produce a weak one. Adding interests to increase coverage weakens **every** match, including strong ones. **Be specific and concise.** A small number of interests you actively work on outperforms a long list. The same applies to tags on opportunities, and to an organisation’s focus areas. ## Distance [Section titled “Distance”](#distance) Distance is banded rather than continuous: | Distance apart | Contribution | | -------------- | ------------ | | Up to 50 km | Full (1.0) | | Up to 200 km | 0.8 | | Up to 500 km | 0.5 | | Up to 2,000 km | 0.2 | | Further | 0.05 | **The bands are measured in kilometres, not by national borders.** Two members at opposite ends of a large country fall into the lowest band, while a cross-border pair 40 km apart falls into the highest. Shared nationality is not what is measured. Where only a country is known, its centroid is used, so a country-level profile is scored from that country’s midpoint. The floor is 0.05 rather than zero so that a relevant match on another continent still appears. As distance accounts for 10% of the score, it acts as a tiebreaker rather than a determinant. ## Weak matches are hidden, not ranked low [Section titled “Weak matches are hidden, not ranked low”](#weak-matches-are-hidden-not-ranked-low) Matches below a relevance threshold are excluded rather than ranked low. A short list therefore indicates that few candidates met the threshold. ## When your matches update [Section titled “When your matches update”](#when-your-matches-update) | You change | Refreshed | | -------------------------------------------------- | ------------------------------------------------- | | Your profile — interests, bio, specialty, location | Within about half a minute | | Your organisation’s profile | Within about a minute, along with affected people | | Nothing | Everything is recomputed nightly regardless | So editing your profile and reloading is a reasonable way to test a change. You do not need to wait for the nightly pass. ## If you are not getting matches [Section titled “If you are not getting matches”](#if-you-are-not-getting-matches) In rough order of how often it is the cause: 1. **Your profile is thin.** Matching reads interests, specialty, focus areas and your written text. Empty fields produce nothing to match on. 2. **Your interests are too broad.** See above — breadth actively lowers scores. 3. **Your tags are unique to you.** Tags are a shared vocabulary; one nobody else uses connects to nobody. Prefer an existing tag that nearly fits over a precise one that stands alone. 4. **There genuinely is not much nearby yet.** Distance is only 10%, so this is rarely the whole story. Note that connection matching and opportunity matching are the same machinery pointed at different things — improving your profile improves both. [My Matches](https://ngostack.org/a/network/matches)Network → My Matches # Finding opportunities > Matches the platform computes for you, and suggestions other people send you by hand. Two distinct types of item appear in the list: **matches**, which are computed, and **suggestions**, which are sent by another member. Both require Solo plan.  The opportunities marketplace[Open `/a/opportunities` in the app](https://ngostack.org/a/opportunities) ## Matches [Section titled “Matches”](#matches) Opportunity matching requires Solo plan and uses the **same engine** as [member matching](/network/matching/), with the same 60/30/10 weighting of shared terms, meaning and distance. What differs is the comparison: an opportunity’s **tags** against your interests and match tags, its country against your location, and its text against yours. The consequence is that **the profile is the input** in both cases. A thin match list is addressed by completing the profile rather than by adjusting the search. **Weak matches are excluded rather than ranked low.** Items below the relevance threshold do not appear, so a short list indicates that few met the threshold. **A flagged opportunity is scored at half weight for all members**, in both directions. See [verification](/opportunities/how-it-works/#verified-unverified-and-flagged). ### One asymmetry in the scoring [Section titled “One asymmetry in the scoring”](#one-asymmetry-in-the-scoring) Completed connections raise match scores with a member, but the bonus applies only in the **member → opportunity** direction. It does not affect the direction that determines whose list your own opportunity appears in, so connection activity does not raise the ranking of your listings for other members. ## Suggestions [Section titled “Suggestions”](#suggestions) Suggestions are Solo plan. Separately, **a member can send an opportunity directly**. It appears under Suggested with any accompanying message, and is unrelated to scoring. | | | | ------------ | ------------------------------------------------------------------ | | **Who** | Any member, to up to **five** people at once | | **Message** | Optional, up to 500 characters | | **Clearing** | Suggestions can be **dismissed**; they do not expire automatically | Suggestion is the less-used of the two mechanisms. Matching identifies what fits a profile, whereas a colleague can identify what fits a member including factors the profile does not record. Up to five recipients can be selected at once, with an optional note. [Opportunity matches](https://ngostack.org/a/opportunities/matches)Opportunities → My Matches [Suggested](https://ngostack.org/a/opportunities/suggested)Opportunities → Suggested # How opportunities work > The marketplace is a needs board, not a jobs board — what that means for posting and finding. Browsing the full marketplace is Solo plan. On Free you still see a teaser on your [dashboard](/start/dashboard/), and public opportunity pages remain readable — what needs a plan is the marketplace itself. The marketplace is a **needs board**: members and organisations post requirements, and the platform matches them against member profiles. It is not a jobs board, and the distinction affects how it is used. ## Posting needs rather than offers [Section titled “Posting needs rather than offers”](#posting-needs-rather-than-offers) There is no mechanism for posting an offer. This is by design: **the profile serves that purpose.** A graphic designer does not post “offering graphic design”; the skill is recorded in the profile, and the member then appears in matches for those requiring design. Posting it as an opportunity would duplicate the profile and match nothing. In summary: * **To request something:** post an opportunity. * **To offer something:** complete your profile. * **To exchange:** post the requirement; the profile already records what is offered. Consequently, **a poor match rate is generally addressed through the profile rather than the search.** Specialty, interests and tags are the fields matching reads. Opening a single opportunity’s full detail is Solo plan. ## What counts as an opportunity [Section titled “What counts as an opportunity”](#what-counts-as-an-opportunity) An explicit, actionable request with a defined end point — one that another member can fulfil and that can be marked complete. Discussions, articles and general interests do not qualify. Every opportunity has a type: ### Opportunity types What kind of thing an opportunity is. Chosen when it is posted. skill service volunteering funding event course collaboration mentorship other ## Purpose and tags [Section titled “Purpose and tags”](#purpose-and-tags) Two fields perform the matching, and warrant the most attention: **Purpose** — free text describing the reason for the listing. It is read semantically, so it should be written as prose rather than keywords. **Tags** — drawn from a vocabulary shared with member profiles. `climate-justice` and `mutual-aid` are the same tag on an opportunity as on a profile, which is what allows the two to match. Use existing tags where applicable; a tag used by no other record produces no overlap. ## Stating the commitment [Section titled “Stating the commitment”](#stating-the-commitment) Two fields set expectations. Detail such as rates, hours or barter terms belongs in the description. ### Compensation How, or whether, an opportunity pays. volunteer paid funding barter unspecified **Time investment** is one of `one-time`, `recurring`, `ongoing` or `flexible`. Funding opportunities can also carry an amount and currency. ## Visibility [Section titled “Visibility”](#visibility) | Visibility | Who | | ----------- | ------------------------------------------- | | **Public** | Anyone, including people without an account | | **Network** | Members only | ## Status over time [Section titled “Status over time”](#status-over-time) ### Opportunity status Where an opportunity is in its life. Set by the poster, except \`expired\`. draft active fulfilled expired closed * **Draft** — visible only to the author. * **Active** — published. * **Fulfilled** — set by the author to record that the need was met. Marking this informs platform reporting on outcomes. * **Expired** — applied **automatically** once the deadline passes; no action is required. * **Closed** — set manually by the author, for any reason. * **Recurring** — a sixth state that cannot be set manually. See below. ### Recurring listings [Section titled “Recurring listings”](#recurring-listings) A **recurring** listing is a known cyclical call: currently closed, and expected to reopen. It cannot be created directly — posting produces either a draft or an active listing. The platform derives the state by identifying calls that run in cycles. This affects browsing, as the default listing includes **active and recurring** items together. A result may therefore not be open at the time of viewing; it is listed so that the next round can be anticipated. ## Verified, unverified, and flagged [Section titled “Verified, unverified, and flagged”](#verified-unverified-and-flagged) Listings carry a verification state: | State | Meaning | | ------------------ | ---------------------------------------- | | **Unverified** | Nothing has checked it yet — the default | | **Auto-verified** | Passed the platform’s automated checks | | **Human-verified** | A person confirmed it | | **Human-rejected** | A person reviewed it and rejected it | | **Flagged** | Marked as questionable | **A flagged listing has its match score halved** — it is pushed down, not removed. It can still be found and still matches, at half the weight it would otherwise carry. If a listing of yours has quietly stopped appearing in other people’s matches, this is the first thing to check. Freshness comes from when the opportunity was last updated, not when it was posted. An opportunity you edit looks current again — so if yours is going stale, updating it genuinely helps rather than being a trick. ## Posting [Section titled “Posting”](#posting) Posting needs Solo plan, and editing an existing one needs Solo plan. For the steps — including pasting a call document and letting the AI fill the form in — see [Post an opportunity](/opportunities/post/). # Post an opportunity > Two ways to create one — paste something and let the AI fill it in, or type it yourself. Needs Solo plan. ## Starting a listing [Section titled “Starting a listing”](#starting-a-listing) Use the **`+` button in the top bar**, which offers *Create Opportunity*, *Create Workspace* and *Create Organization*. A create button is also present on the Opportunities page. The remainder takes place in a dialog; the current page is not left. [Opportunities](https://ngostack.org/a/opportunities)Or start from the + menu, anywhere ## Two entry methods [Section titled “Two entry methods”](#two-entry-methods) The first step selects the entry method.  Step one: paste something and let the AI read it, or go straight to the form.[Open `/a/opportunities` in the app](https://ngostack.org/a/opportunities) **Paste & Autofill** — paste a posting, an email or a brief, enter content directly, or attach files. The AI reads the input and populates the fields. **Fill Manually** — proceed directly to the empty form. **Autofill consumes the organisation’s AI allowance.** The dialog displays usage for the current month against that allowance. The allowance is shared across the organisation rather than held per member, which is why the figure is shown. Autofill is intended for existing source material Where the opportunity already exists as text — a funder’s call document, an email from a partner, or a description written for another platform — paste it. The input is source material rather than a prompt. Starting from nothing, Fill Manually is faster than composing text to paste. Both methods lead to the same second step. Autofill does not submit the listing; it populates the fields for review.  Autofill output from a funder's call page: it picked the type, the deadline and the source link.[Open `/a/opportunities` in the app](https://ngostack.org/a/opportunities) From a single URL it derived the type, the deadline, the source link and five tags — `biodiversity`, `conservation`, `wallacea`, `indonesia`, `grants` — of which `indonesia` was inferred, as the source page does not state it. **Two fields are consistently left unpopulated** and should be completed manually: | | | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Compensation** | Left as `unspecified` even on a funding call, because amounts are rarely written in a form it can parse. An opportunity left unspecified will not surface for anyone filtering by compensation. | | **UN SDGs** | Not attempted at all — and the cost is the same as leaving compensation blank. SDGs are a browse filter, and **a listing with none is never returned by it**. Pick up to five goals from the seventeen. | The description is a summary of the source page and should also be reviewed as a draft. ## Completing the details [Section titled “Completing the details”](#completing-the-details)  Step two: review and complete. The same form whichever route you took.[Open `/a/opportunities` in the app](https://ngostack.org/a/opportunities) 1. **Check the type.** Autofill infers it; confirm it matches what a member searching would select. The full list is in [the vocabulary reference](/reference/vocabulary/#opportunity-types). 2. **Check the title.** For most members this is the only text seen. State the requirement directly — “Web developer for a 3-month campaign site” rather than a general announcement. 3. **Review the description and purpose.** These are the fields autofill is most likely to misstate, as both summarise source text. Purpose is read semantically, so it should remain prose. 4. **Correct the tags.** Tags share a vocabulary with member profile interests, so `climate-justice` on a listing matches `climate-justice` on a profile. **Select existing tags**; a tag used by no other record produces no overlap. 5. **Select SDGs.** Up to five of the seventeen UN Sustainable Development Goals. Autofill does not populate these, and a listing with none is not returned by SDG-filtered browsing. 6. **Set compensation and time investment.** Compensation is `volunteer`, `paid`, `funding`, `barter` or `unspecified`; time investment is `one-time`, `recurring`, `ongoing` or `flexible`. 7. **Set the location, or mark it remote.** A **Remote** switch accompanies country and city. Location feeds the distance component of matching, which acts as a tiebreaker rather than a filter, so an approximate city is preferable to an empty field. 8. **Choose visibility.** `public` is anyone including signed-out visitors; `network` is members only. 9. **Set a deadline.** With one, the listing expires automatically. Without one it remains active until closed manually. 10. **Publish.** A draft is visible only to its author. ## After publication [Section titled “After publication”](#after-publication)  Everything you have posted, split by active, draft and past.[Open `/a/opportunities/me` in the app](https://ngostack.org/a/opportunities/me) Posted listings are under **My Listings**, which is Solo plan. **Mark the listing fulfilled once the need is met.** This informs platform reporting on outcomes, and prevents members from responding to a closed requirement. **Editing refreshes it.** Freshness is measured from the last edit, not the post date — so revising a stale listing genuinely helps. [Your listings](https://ngostack.org/a/opportunities/me)Everything you posted ## Changing and removing a listing [Section titled “Changing and removing a listing”](#changing-and-removing-a-listing) **Editing also affects ranking.** Freshness is measured from the last edit, so an edit both corrects the content and raises the listing. Editing requires Solo plan. **Deletion removes a listing from view without erasing it.** A deleted opportunity is soft-deleted: it ceases to appear while the record is retained. Deletion is therefore a withdrawal rather than an erasure, which is material where the reason for deleting is a privacy concern. **A status change is preferable to deletion.** Marking a listing **fulfilled** records that the need was met; **closed** records that it was withdrawn. Both preserve the history and both contribute to platform reporting. Deletion records neither. Delete a listing created in error; close one that represents a decision. ## Summary [Section titled “Summary”](#summary) There is no mechanism for posting an *offer*; the profile serves that purpose. Tags are the primary means by which matching locates a listing. [How opportunities work](/opportunities/how-it-works/) · [How matching works](/network/matching/) # Setting up an organisation > The recommended order — profile, verification, subscription, members, then work — and why the sequence affects cost. Organisation setup follows a recommended sequence. The sequence affects cost, not only scheduling. All of the steps below are performed on a single screen, which has four tabs: **Profile**, **Verification**, **Storage** and **Settings**.  The organisation settings screen, as it opens[Open `/a/settings/organization` in the app](https://ngostack.org/a/settings/organization) 1. **Create the organisation and set its country.** The country determines which non-profit pricing band the organisation is eligible for. 2. **Complete the profile.** Logo, description and organisation type. Verification remains locked until the required fields are complete. → [Your organisation](/organization/manage/) 3. **Request verification.** A reviewer assesses the request. On approval, the pricing band is assigned automatically from the country set in step one. 4. **Subscribe.** Checkout applies the band automatically if it is already assigned. → [What your plan includes](/start/plans/) 5. **Invite members.** Members, invitations and join requests are managed on the Members screen. Add a second administrator at this point: if a sole administrator deletes their account and there is no one to promote, the organisation is deleted with them. 6. **Begin the work.** A [project](/projects/create/) for a programme, a [workspace](/workspaces/create/) for work produced with other organisations, or a [space](/spaces/wiki/) for material that needs to be written down. ## Order of operations [Section titled “Order of operations”](#order-of-operations) Steps three and four are the only sequence on the platform with a cost attached. Every other step can be reordered or repeated. Subscribing before verification is approved is not, however, irreversible. Checkout has no band to apply at that point, but when approval is granted the reduced rate is applied to the existing subscription. Only invoices raised before approval remain at the standard rate; they are not refunded or back-dated. If approval is granted during the trial period, no charge has been raised and the subscription converts at the reduced rate. The remaining order follows from the dependencies: the profile is required for verification, verification determines pricing, members require an organisation to join, and work requires members. [Organization](https://ngostack.org/a/settings/organization)Settings → Organization # Your organisation > The organisation profile, the verification process, and member management. An organisation owns projects, holds a subscription and can be verified. It is administered from two screens: **Organization** and **Members**. ## The profile [Section titled “The profile”](#the-profile) **Settings → Organization** has four tabs: **Profile**, **Verification**, **Storage** and **Settings**. Profile holds the logo, the description, and an **organisation type** selected from a fixed list: NGO, Foundation, Association, Cooperative, Community Group, Social Enterprise, Startup, Network / Alliance, Research Group, Informal Collective, Public Institution, or Other. Selecting Other enables a free-text field. The type is assessed as part of verification, and is displayed to other organisations evaluating a collaboration. ## Verification [Section titled “Verification”](#verification) Verification has five states: | State | Meaning | | --------------------------- | --------------------------------------------- | | **Unverified** | The default. Nothing has been reviewed | | **Pending** | Requested, and awaiting a reviewer’s response | | **Verified** | Approved | | **Suspended** · **Revoked** | Withdrawn after approval | **Verification determines the pricing band.** On approval, the non-profit tier is assigned from the organisation’s country income group, and checkout applies that band from then on. Requesting verification before subscribing is therefore recommended — see [What your plan includes](/start/plans/#non-profit-pricing-request-verification-before-subscribing) for the sequence and its cost implications. ### Requesting it [Section titled “Requesting it”](#requesting-it)  Requesting verification — documents, types and notes for the reviewer[Open `/a/settings/organization` in the app](https://ngostack.org/a/settings/organization) 1. **Complete the organisation profile.** Verification is locked until the required fields are complete. The tab states this and links back to Profile rather than accepting a request that would be rejected. 2. **Upload the supporting documents.** Each is filed under a type: Registration Certificate, Tax Certificate, Annual Report, Proof of Address, Articles of Incorporation, or Other. **PDF, JPEG, PNG or WebP, up to 10 MB each.** 3. **Add notes for the reviewer.** Optional. Use this for context the documents do not carry — an unusual legal form, a name that differs between documents, or a registration from a jurisdiction whose certificates may be unfamiliar. 4. **Submit the request.** The organisation moves to **pending** and a reviewer assesses it. Review is performed by a person and is not immediate. The pricing band is assigned only on approval, so organisations intending to subscribe should allow for the review period. This is also the subject of the [dashboard](/start/dashboard/) prompt reporting an incomplete organisation profile. ## Members [Section titled “Members”](#members) **Settings → Members** has three tabs: **Members**, **Invitations** and **Join Requests**. **Invitations** are issued by the organisation. **Join requests** are submitted to it, and remain outstanding until an administrator responds — which is why [join request alerts](/settings/notifications/) are a separate notification. Members hold a **role**. Administrators can manage the organisation; ordinary members cannot. **Confirm you are not the sole administrator before deleting your account.** A sole administrator’s departure promotes a replacement, or deletes the organisation if there is no one to promote. See [your account and your data](/settings/account/#sole-administrators). [Organization](https://ngostack.org/a/settings/organization)Settings → Organization # Budget and expenses > Categories, expenses, receipts, importing an existing budget, and freezing a snapshot for a donor. Projects need Org plan. A project budget is a set of **categories**, each with a planned amount, against which you record **expenses**. Both live on the project’s **Budget** tab.  The budget: spend to date, by category, over time[Open `/p` in the app](https://ngostack.org/p) ## Categories [Section titled “Categories”](#categories) Seven categories are suggested — personnel, travel, consultants, equipment, training, overhead and other — but **the list is not fixed**. Additional categories can be created, and recording an expense against a category that does not exist creates it. Two behaviours apply: **Names are matched loosely.** “Travel”, “travel” and “ Travel “ resolve to the same category, as names are trimmed, collapsed and lowercased before comparison. A budget therefore does not fragment across spelling variants. **Categories carry a code prefix.** The built-ins are fixed: `PER`, `TRV`, `CON`, `EQP`, `TRN`, `OVH`, `OTH`. A category you create derives its prefix from the first three letters of its name. ### Planned amounts and the overview [Section titled “Planned amounts and the overview”](#planned-amounts-and-the-overview) A category created by recording an expense has no planned amount. Until every category has one, there is no budget overview: no total, burn rate or status. The mechanism and the remedy are documented in [Milestones](/projects/milestones/#assigning-planned-amounts-to-categories). Once amounts are set, each category reports a **burn status**: on track, underspent, overspent, or no data.  A budget category, with the switch that gives it a planned amount[Open `/p` in the app](https://ngostack.org/p) Note the control’s location: once a budget contains categories, **Add Budget Category** is no longer a separate button but the menu portion of the **Add Expense** split button. **Currency is fixed at project level** rather than per category. Currencies cannot be mixed within one budget. ## Expenses [Section titled “Expenses”](#expenses) An expense records an amount, a description, a date, and optionally a vendor reference and the **milestone** it belongs to. The milestone association is what enables spend-against-plan reporting per phase rather than in total only.  Recording an expense — category, milestone, and the receipt[Open `/p` in the app](https://ngostack.org/p) **Entries can be created from the receipt.** Attaching one and selecting **Scan with AI** reads the document and populates the fields below it. This is equivalent to autofill when [posting an opportunity](/opportunities/post/), and the same caution applies: the output is a draft requiring review. Receipts must be **PDF, JPEG or PNG, up to 15 MB**. Receipts are **served behind the project’s authentication** rather than from a public URL, and can be replaced or removed subsequently. An expense can be **edited or reassigned to a different category**, so a misfiled cost is corrected rather than deleted and re-entered. ### Removing and reordering [Section titled “Removing and reordering”](#removing-and-reordering) **Categories** can be deleted individually or in bulk, and **reordered**. The order determines how the budget is presented to any reader, including within a snapshot, and should be set deliberately. **Expenses** can be deleted individually, and a **receipt can be removed** from an expense without deleting the expense. This applies where a receipt was attached to the wrong line or contains material that should not be shared. Deleting a category containing expenses warrants care: the expenditure is retained, but the category it was reported under is not. Where the categories match a structure agreed with a funder, move the expenses first. ## Importing an existing budget [Section titled “Importing an existing budget”](#importing-an-existing-budget) An existing budget need not be re-entered. Budget lines can be **bulk-imported from CSV or spreadsheet data**. Each row requires at least a category and a currency; the planned amount is optional. This is the appropriate approach where a funder has supplied the budget structure: import their categories and record against them, so that reporting aligns without a subsequent mapping exercise. ## Snapshots [Section titled “Snapshots”](#snapshots) A **snapshot** is a frozen copy of the budget at a point in time, retained for donor reporting. A live budget continues to change. A report issued in March describes figures that may since have altered, and without a snapshot there is no record of what was accurate at the time of issue. Taking a snapshot when reporting preserves the figures quoted. Snapshots are read-only once taken, and can be listed and deleted. ## Limits [Section titled “Limits”](#limits) | | | | ------------------------ | --- | | Budget lines per project | 200 | | Expenses per budget line | 500 | | Snapshots per project | 50 | These limits are not normally reached. A budget imported from a spreadsheet with one line per transaction can reach the first: categories are aggregates, and per-transaction detail belongs in expenses. [Your projects](https://ngostack.org/p)Projects # Create a project > Starting a project, choosing who can see it, and what to fill in afterwards rather than first. Projects need Org plan. A project belongs to an **organisation** rather than to an individual, so switch to the correct organisation before creating one. This is also why the projects list follows the organisation switcher, unlike [workspaces](/workspaces/vs-spaces/).  Starting a project — title, description and who can see it[Open `/p` in the app](https://ngostack.org/p) 1. **Open Projects and choose New Project.** 2. **Give it a title.** This is the only required field. 3. **Add a brief description.** Optional. It appears beneath the title wherever the project is listed. 4. **Choose visibility.** Three levels, and the default is the closed one: | | Who can see it | | ----------------------- | ---------------------------------------- | | **Private** *(default)* | Only people added to the project | | **Organization** | Anyone in the organisation that owns it | | **Public** | Anyone, including people with no account | 5. **Create the project.** It opens at status **Planning**, with the creator as **Owner**. ## Completing the project after creation [Section titled “Completing the project after creation”](#completing-the-project-after-creation) The creation dialog requests minimal information by design. Goals, members, milestones and budget are added after the project exists; there is no setup wizard to complete first. The recommended order: 1. [Milestones](/projects/milestones/) — the phases, which everything else hangs off. 2. [Budget](/projects/budget/) — categories with planned amounts, so spend has something to compare against. 3. [Updates and evidence](/projects/updates/) — as the work happens. 4. [Reports](/projects/reports/) — when someone asks. [Planning results](/projects/planning-results/) applies alongside these and should be read **before it is required**, as the results-planning mode can only be advanced, not reversed. ## Status is set manually [Section titled “Status is set manually”](#status-is-set-manually) A project moves through **planning → active → on hold → completed → abandoned**. No transition is automatic: the status remains at Planning until it is changed, including after work has started. Two consequences follow. A stale status presents the project as dormant to anyone reading the list, and a generated [report](/projects/reports/) describes the project as being at whatever stage the status records, since reports quote it directly. ## Changing and deleting a project [Section titled “Changing and deleting a project”](#changing-and-deleting-a-project) A project’s details can be edited at any time. Title, description and visibility are all revisable, and a visibility change takes effect immediately for all viewers. **Deletion is soft.** The project ceases to appear while the record is retained. Milestones, budget, updates and evidence are removed with it, so deleting a project in order to restart discards the history. Where a project is finished or abandoned, **set its status** rather than deleting it. The `completed` and `abandoned` statuses exist for this purpose and preserve the record. ## Project and update visibility differ [Section titled “Project and update visibility differ”](#project-and-update-visibility-differ) A project is created **private**. An [update](/projects/updates/) posted within it is created **public**. The two defaults are opposed: restricting a project’s visibility does not restrict its updates. Check an update’s visibility before publishing rather than assuming it inherits the project’s. [Your projects](https://ngostack.org/p)Projects # Impact evidence > A measurement recorded properly — what a record carries, the three verification states, and why there is no edit. Projects need Org plan. **Evidence** records the measurement behind a narrative. An [update](/projects/updates/) stating “we trained 40 women in Kisumu this month” is the narrative; the corresponding evidence records `beneficiaries trained = 40` for a stated period, with a method and a source. Evidence is available in **every** results-planning mode, including Simple. It is not gated by the [logframe mode](/projects/planning-results/). ## Evidence [Section titled “Evidence”](#evidence) Each evidence record carries the following fields: | Field | What it is | | ---------------------- | ------------------------------------------------------------------------- | | **Indicator** | What was measured — “trees planted”, “beneficiaries trained” | | **Value** and **unit** | The figure, and what it counts | | **Baseline** | The position before the project. *Not requested in the form — see below.* | | **Target** | The committed figure. *Not requested in the form — see below.* | | **Period** | The window the measurement covers, from and to | | **Methodology** | How the figure was derived | | **Source** | A field note, survey, or report | | **Location** | Where the measurement applies, where relevant | | **Media** | Supporting photographs or documents | Evidence can be attached to a milestone and, in Standard or Advanced logframe mode, to a planned indicator. This places the planned target and the actual measurement together. Baseline and target are stored on every evidence record, but **the Add Evidence form does not request them**. They belong to the planned indicator rather than to an individual measurement: in Standard or Advanced mode they are taken from the logframe indicator the record is linked to, and in Simple mode, where no planned indicator exists, they remain empty. ### Correcting a record [Section titled “Correcting a record”](#correcting-a-record) Evidence can be deleted. Deletion is soft: the record is retained while ceasing to appear. There is no supersede-and-retain flow. Where a measurement was incorrect, delete it and record the corrected figure rather than editing the value, which would remove the fact that it changed. ### Verification [Section titled “Verification”](#verification) Every record carries a verification status: **unverified**, **pending**, or **verified**. New evidence is created unverified. Recording a measurement does not assert that it has been checked, and the status is visible to readers.  Evidence records, each carrying its source and verification state[Open `/p` in the app](https://ngostack.org/p) The Evidence tab lists each record with its value, period, source and verification state. Records from the same project may hold different states simultaneously; this is expected rather than a backlog requiring resolution. [Your projects](https://ngostack.org/p)Projects ## A known limitation [Section titled “A known limitation”](#a-known-limitation) **Indicators are free text.** “trees planted”, “Trees Planted” and “# of trees planted” are treated as three distinct indicators and will not aggregate across projects or periods. Where totals are required — across projects, across years, or in a funder report — **agree the exact wording of each indicator within the organisation and use it verbatim.** Establishing this convention in advance avoids a reconciliation that cannot be performed by query. # Milestones > Breaking a project into phases you can track, budget against and report on. Projects need Org plan. A milestone is a phase of work with a start date, an end date, an owner and an allocated share of the budget. It is the unit in which a project is tracked, and the unit funders typically report against. Milestones live on their own tab inside a project, alongside Overview, Budget, Feed, Evidence and Reports.  The milestones table — status, due date and spend against plan[Open `/p` in the app](https://ngostack.org/p) ## Adding one [Section titled “Adding one”](#adding-one) Open a project, go to **Milestones**, then **Add Milestone**. The dialog asks for: | Field | Notes | | -------------------- | ----------------------------------------------------------- | | **Title** | Required. What this phase delivers. | | **Description** | Optional. Displayed beneath the title in the table. | | **Status** | Planned, Active, Completed or Cancelled. Starts at Planned. | | **Owner** | Optional. Someone already on the project. | | **Starts** / **Due** | The span. Both feed the timeline view. | | **Planned budget** | What this phase is expected to cost, with its currency. | None of these values is permanent. A milestone can be edited or removed subsequently, unlike the project’s [results planning mode](/projects/planning-results/), which can only be advanced. ## Three views of the same milestones [Section titled “Three views of the same milestones”](#three-views-of-the-same-milestones) The switcher on the right offers **Timeline**, **Board** and **Table**. Table opens by default and is the only view showing spend against plan. * **Timeline** places each milestone across its start-to-due span, showing overlap and sequence. * **Board** groups milestones into columns by status, for week-to-week management. * **Table** lists them with status, due date and **spent / planned**, for financial review. All three present the same records. No data is view-specific, so a milestone added in one view appears in all three.  The same milestones on the board — grouped by status[Open `/p` in the app](https://ngostack.org/p) The board has one column per status, including **Cancelled**, which remains visible when empty so that cancelled phases are not hidden.  The same milestones on the timeline — span and overlap[Open `/p` in the app](https://ngostack.org/p) ## The summary counters [Section titled “The summary counters”](#the-summary-counters) The summary line reads `4 total · 1 active · 1 completed · 1 overdue`. **Overdue is derived rather than set**: it indicates that the due date has passed while the milestone is not Completed. A milestone marked Active with a past due date is counted as both active and overdue. In the preceding screenshot, the baseline survey is Active and past its due date, so it carries an **Overdue** badge while remaining in the active count. This is expected rather than a data fault. ## Completing one milestone is not the same as completing several [Section titled “Completing one milestone is not the same as completing several”](#completing-one-milestone-is-not-the-same-as-completing-several) Marking a milestone **Completed** individually posts a system update to the project feed and notifies the project. Selecting several using the checkboxes in the Table view and setting their status collectively does **neither**: it changes the status and records the completion date only. This is deliberate. Bulk editing is treated as an administrative correction rather than as reportable progress. Where several phases are genuinely being completed and the team should be notified, complete them individually. ## Changing and removing milestones [Section titled “Changing and removing milestones”](#changing-and-removing-milestones) Milestones can be edited without restriction, unlike the project’s [results-planning mode](/projects/planning-results/). **Deletion is soft and clears associated tags.** A deleted milestone ceases to appear while the record is retained, and its **advisory tags are cleared**, so anything tagged to it loses that association. Where work is being reorganised rather than removed, move it before deleting. **Milestones can be reordered.** The order determines how the timeline and board present them and should be set deliberately rather than left in creation order. ## Budget follows milestones [Section titled “Budget follows milestones”](#budget-follows-milestones) Each milestone carries a planned amount, and the Table view shows **spent / planned** per milestone. Expenditure is recorded on the **Budget** tab rather than here. Recording an expense creates the budget category automatically where one does not exist, so a chart of accounts need not be defined before the first cost is recorded. Categories can also be defined in advance using **Add Budget Category** on the Budget tab, where the budget structure is set externally.  The budget: spend to date, by category, over time[Open `/p` in the app](https://ngostack.org/p) ### Assigning planned amounts to categories [Section titled “Assigning planned amounts to categories”](#assigning-planned-amounts-to-categories) A category created by recording an expense has **no planned amount**, and the consequence extends beyond a single column. Until every category has a budget, Planned displays “No budget”, Remaining and Used are blank, and the **Budget overview panel is not displayed**: no total, burn rate, on-track status or allocation chart. Expenditure continues to be tracked correctly throughout; what is absent is a basis for comparison. Set the amounts from the row menu — **Edit Budget Category**, then enable *“give this budget category a planned amount”* — and the overview appears, with totals and burn rate computed from the expenditure already recorded. **Currency is fixed per project rather than per category.** Currencies cannot be mixed within one budget. ## The limits of milestones [Section titled “The limits of milestones”](#the-limits-of-milestones) A milestone is programme structure rather than a task list. Where a phase requires several people or organisations to collaborate directly — drafting, reviewing, or dividing work — that belongs in a workspace, and a milestone can have a workspace of its own. The distinction is documented in [Project or workspace?](/projects/vs-workspaces/). [Your projects](https://ngostack.org/p)Projects # Planning results > The three levels of results planning, and the criteria for selecting between them. Projects need Org plan. Every project has a **results planning mode**, set initially to the simplest. This page documents the modes and the conditions under which upgrading is appropriate. ## Simple mode is the default [Section titled “Simple mode is the default”](#simple-mode-is-the-default) **Simple** mode deliberately contains no results-planning constructs. It provides a total budget with category buckets, and outcomes are recorded through updates and evidence. There are no objectives, indicators or hierarchy. For a community grant of approximately €5,000–€50,000 where no logical framework has been requested, Simple mode is sufficient and the remainder of this page does not apply. Applying institutional planning structure to a small project produces work without producing anything the funder has required. ## The three modes [Section titled “The three modes”](#the-three-modes) | Mode | Suits | Results planning | Budget | | ---------------------- | -------------------------------------------------- | -------------------------------- | ------------------------------------------ | | **Simple** *(default)* | Micro-grants, community projects | None — updates and evidence only | Total plus category buckets | | **Standard** | Small to mid institutional, roughly €50k–€500k | A flat list of outcomes | Line items with funder attribution | | **Advanced** | Institutional funders that require a full logframe | Four-level hierarchy | Line items, revision history, funder split | Two points apply before changing mode: **Updates and evidence are available in every mode** and are never gated. A project remaining in Simple mode retains complete results tracking; the mode controls only whether the *planning* layer is available. **Modes can be upgraded but not downgraded.** Simple → Standard → Advanced is a one-way transition. Upgrading exposes additional capabilities without altering existing records, but cannot be reversed, so it should be treated as a decision rather than a trial. ## Standard mode [Section titled “Standard mode”](#standard-mode) Standard mode provides outcomes as a flat list, without nesting. Each outcome carries indicators, and the budget becomes line items that can be attributed to funders. Assumptions and means of verification exist in the data model but are **not** available in Standard mode, and are not offered by the interface. Where they are required, Advanced mode applies. ## Advanced mode [Section titled “Advanced mode”](#advanced-mode) Advanced mode implements the Logical Framework Approach in full, this being the convention used by institutional development funders. It has four levels: | Level | What it is | | ------------ | ---------------------------------------------- | | **Goal** | The long-term change being contributed to | | **Outcome** | The change the organisation is accountable for | | **Output** | What the work directly produces | | **Activity** | The work undertaken | These are the standard Logical Framework Approach definitions rather than platform-specific ones. Where a funder’s guidance defines them differently, follow the funder. Each level nests beneath the one above. Advanced mode also provides **assumptions** — the conditions that must hold for the logic to remain valid — and **means of verification** on each indicator. ### Funder terminology [Section titled “Funder terminology”](#funder-terminology) Every objective can carry a **label** that overrides the level name. Where a funder refers to an outcome as a “Specific Objective”, set that as the label; the underlying structure is unchanged. Funder templates are vocabulary applied to a single structure rather than distinct structures. A logframe does not need rebuilding to satisfy a different funder’s terminology. ## Indicators [Section titled “Indicators”](#indicators) An indicator is the measure by which an objective’s achievement is assessed. Each has: | Field | For | | ------------------------- | ----------------------------------------------------------- | | **Name and unit** | What is counted, and in what unit | | **Type** | Quantitative or qualitative | | **Baseline** and its date | The position at the start | | **Target** and its date | The intended position | | **Frequency** | Measurement interval: monthly, quarterly, annual, or ad-hoc | | **Means of verification** | How the result is evidenced — *Advanced mode only* | Evidence attaches to indicators. Recording evidence against an indicator places the planned target and the actual measurement together, which is the purpose of setting a baseline as well as a target. ## Rejected operations [Section titled “Rejected operations”](#rejected-operations) | Operation | Reason | | -------------------------------------------------- | -------------------------------------------------- | | Creating an objective in Simple mode | Results planning is not enabled; change mode first | | Nesting one outcome under another in Standard mode | Hierarchy is available in Advanced mode only | | Using a level other than outcome in Standard mode | Standard mode supports outcomes only | Setting assumptions or means of verification in Standard mode is **not** rejected but ignored. The fields are not part of that mode, so the values are not saved and no notification is given. # Reports > Generating a funder-ready report from what the project already records — including from a funder's own template. Projects need Org plan. Reports are Org plan. A report is assembled from records already held by the project: milestones, evidence, updates and budget. The period and structure are selected; the content is not re-entered.  A generated progress report, open beside the report list[Open `/p` in the app](https://ngostack.org/p) ## Generating one [Section titled “Generating one”](#generating-one) Select the **Reports** tab, then **Generate report**. Set the period first; the remaining options determine presentation. ### The readiness panel [Section titled “The readiness panel”](#the-readiness-panel) Once a period is set, the dialog reports whether that window contains sufficient data for a meaningful report, and lists outstanding items — for example *“1 milestone(s) are overdue”*. The panel checks the same data the report will draw on, so a warning indicates a gap that would otherwise appear as an incomplete section in the delivered report. ### Structure [Section titled “Structure”](#structure) Two ready structures ship with it: | Base | For | | ---------------------------- | ----------------------------------------------------------------- | | **Standard progress report** | The usual narrative shape — summary, progress, evidence, finances | | **IATI-conformant report** | Where you publish to the IATI standard | Alternatively, supply **the funder’s own template** and the structure is derived from it: upload a file (Word, PDF, Excel, HTML or plain text), paste the text, or paste a link. This addresses the common case in which a funder’s form matches neither standard structure. ### Language and type [Section titled “Language and type”](#language-and-type) Ten languages are available: English, German, French, Spanish, Portuguese, Dutch, Swedish, Norwegian, Italian and Danish. The report is written in the selected language rather than translated afterwards. Seven types are available: Default, Progress, Annual, Final, Financial, Narrative and Ad-hoc. The type determines emphasis and the report’s name. ## What comes out [Section titled “What comes out”](#what-comes-out) A draft document of eight sections: Executive Summary, Project Overview, Progress & Milestones, Impact Evidence, Financial Overview, Key Challenges & Lessons Learned, Planned Activities and Conclusion. A **Download PDF** control is provided. Four properties of the output: **It is created as a Draft and is versioned.** The list displays `Progress · v1`. Generating a report does not transmit it. **Draft status is enforced: submitting locks the report.** *Mark submitted* freezes it; *Re-open to draft* unlocks it. This should be applied once a report has been sent to a funder, to prevent the delivered document being regenerated. **Each section records its provenance.** Sections carry a *From your data* marker and a **Sources** list identifying the records used — the project profile, milestones, and evidence records. **Generation takes several minutes.** The document is read and written in full. ## Export options [Section titled “Export options”](#export-options) **Download PDF** is the primary control. The **⋮** menu beside it holds the remainder: | | | | ------------------------------------- | ---------------------------------------------------- | | **Download Word (.docx)** | For a funder who wants to comment or reuse your text | | **Download Markdown** | For pasting into another system | | **Share link…** | A read-only link to the report itself | | **Regenerate** | Re-run the analysis | | **Mark submitted / Re-open to draft** | Lock or unlock | | **Delete** | Remove it | ### Share links are capability URLs [Section titled “Share links are capability URLs”](#share-links-are-capability-urls) A share link carries a long, unguessable token, and **any holder of the link can read the report without signing in**. This is intentional, so that a funder does not require an account. It also means the link constitutes the permission: forwarding the link forwards the access. A link can be **revoked**, and revocation is the only means of withdrawing access. Links do not expire. ## Exporting the whole project as IATI [Section titled “Exporting the whole project as IATI”](#exporting-the-whole-project-as-iati) Separately from reports, a project can be exported as **IATI Activity Standard 2.03 XML** — the publication format used for aid transparency reporting. This is distinct from the [IATI-conformant report](#structure): the report is a document written in IATI’s conventions for a human reader, whereas the XML export is the machine-readable activity record for publication to the IATI registry. ## Logframe inclusion [Section titled “Logframe inclusion”](#logframe-inclusion) Where results have been planned, they are included: each objective with its level and description, and beneath it every indicator with its unit and target. Evidence is included alongside, each measurement carrying its value, baseline, target and verification state, so planned and actual figures appear together. Two limits apply and neither is reported: **at most 20 objectives** are included, and the logframe block is truncated if it exceeds the available length. A large logframe is therefore summarised rather than reproduced in full, and the generated section should be checked against the plan before the report is sent. [Your projects](https://ngostack.org/p)Projects # Project updates > The story of a project — who sees it, what publishes itself, and the audience most people never use. Projects need Org plan. An **update** is the narrative record: what happened, in text and images. The corresponding measurement is [evidence](/projects/evidence/), and both are generally required. An update comprises a caption, media, and optionally a link and a location. Three constraints apply: **Captions support inline formatting but not structure.** The toolbar provides **bold**, *italic*, underline, links and hashtags; typing `#something` marks it as a hashtag. Headings, lists and embedded blocks are not available, so a caption is one or more paragraphs rather than a document. Where structure is required, use multiple updates or attach a file. **Captions are limited to 2,200 characters.** Content exceeding this generally belongs in an attached document or a [wiki page](/workspaces/vs-spaces/). **A link preview is captured once, at the time of posting.** The title, description and image are read from the target page at that moment and stored. Subsequent changes to the page are not reflected: the link continues to work, but the preview is a snapshot rather than a live view. ### System-generated updates [Section titled “System-generated updates”](#system-generated-updates) Completing a milestone generates an update automatically. These are marked as system-generated and **cannot be edited or rewritten**. Where a system update states something incorrect, amend the milestone rather than the post. ## Who can see an update [Section titled “Who can see an update”](#who-can-see-an-update) Four levels are available: | Visibility | Who sees it | | ----------- | ------------------------------------------------ | | **Public** | Anyone, including people with no account | | **Org** | Anyone in the organisation that owns the project | | **Members** | Only people explicitly added to the project | | **Funders** | Your funders — see below | **The default is Public.** The composer opens at this setting, so an update published without changing it is visible to anyone, including users without an account. Set the visibility *before* publishing. **Funders is an enforced audience rather than a label.** A member qualifies where they belong to a funder organisation holding an *active* funding relationship with the project. This allows reporting to funders without publishing publicly and without adding them to the project. This tier is intended to replace reporting by email. Material written for a funder should be posted here rather than sent. Note that **org** and **members** are distinct: organisation membership does not confer project membership. See [Project or workspace?](/projects/vs-workspaces/).  The project feed — updates as the public sees them[Open `/p` in the app](https://ngostack.org/p) The feed offers two views, **Table** and **Gallery**. Each post displays its state and audience, so the visibility of a published update can be confirmed without opening it. ### Publishing and drafts [Section titled “Publishing and drafts”](#publishing-and-drafts) The composer provides **Save draft** and **Publish now** as separate controls. A draft remains in the feed marked as such and is published only on the publish action. The composer also **retains unsaved text**. Closing it mid-entry preserves the content, which is offered again when the composer is next opened. ### Changing and removing updates [Section titled “Changing and removing updates”](#changing-and-removing-updates) An update can be edited or deleted after publication, and updates can be **published, unpublished or deleted in bulk** from the list. **Unpublishing is generally preferable to deletion.** It removes an update from view without destroying it, which is the appropriate response where something was published prematurely or to the wrong audience. Deletion is irreversible. The exception is the [system-generated updates](#system-generated-updates) produced by a completed milestone, which cannot be edited or rewritten. [Your projects](https://ngostack.org/p)Projects # Project or workspace? > Two containers that sound interchangeable and are not. Neither contains the other. In summary: a **project** is the initiative; a **workspace** is where work is produced. They are **peers rather than a hierarchy.** Neither contains the other. A project may generate any number of workspaces over its life, including none, and a workspace may exist without a project. ## Selecting between them [Section titled “Selecting between them”](#selecting-between-them) | | Project | Workspace | | ----------------- | -------------------------------------------- | ----------------------------------------- | | Owned by | One organisation | No owning organisation | | Membership | The organisation’s team and stakeholders | Partners across organisations, and guests | | Typical duration | Months to years | Weeks to months | | Structured around | Milestones and phases | Deliverables and contributions | | Purpose | Planning and tracking | Producing work collaboratively | | Ends when | Goals are met, funding ends, or it is closed | The output is compiled and delivered | Work describing what an organisation is trying to achieve is a project. Work produced with members of other organisations is a workspace. ## A project is programme structure [Section titled “A project is programme structure”](#a-project-is-programme-structure) A project is **not** a Gantt chart, an issue tracker, or a grant-management system. This is the most common source of mismatched expectations. There are deliberately **no sub-tasks, no assignments and no Kanban board**. Work at the level of “write section 3” has no location here by design. The distinction the platform draws: | A task tracker asks | A project asks | | ----------------------- | --------------------------------- | | Was the task completed? | Did the phase deliver its output? | | Tracks activities | Tracks commitments | ## Milestones and deliverables [Section titled “Milestones and deliverables”](#milestones-and-deliverables) | | Milestone *(project)* | Deliverable *(workspace)* | | ------------------- | --------------------------- | ------------------------------- | | What it is | A strategic output, a phase | A tactical output | | For example | “Youth training curriculum” | “Module 3: Conflict Resolution” | | Where it comes from | The workspaces you linked | Contributions from partners | The two are the same concept at different levels. **A milestone is delivered through a workspace rather than assembled directly**, whereas a deliverable is assembled from partner contributions. ## Example [Section titled “Example”](#example) A funded programme illustrates the relationship: * The **project** runs for three years and holds the milestones reported to the funder. * Milestone one, “develop the curriculum”, generates a **workspace** in which three organisations compile it. That workspace is archived once the curriculum is complete. * Milestone two, “pilot in five countries”, generates a **separate** workspace with different partners. * Milestone three, “publish the final report”, is internal and requires no workspace. The project outlives each of them. ## Two constraints [Section titled “Two constraints”](#two-constraints) **Projects are owned by an organisation, never by an individual.** Funding is disbursed to organisations, so this is a fixed constraint. Members without an organisation can still use matching, connections and opportunities, and join or create an organisation when they are ready to run an initiative. **Organisation membership does not confer project membership.** Project members are added explicitly, and only project members can view the project. An organisation of forty members should not have all forty within every initiative. *** Wiki spaces are a third construct, and they scope in the opposite direction to workspaces. See [Workspaces and spaces](/workspaces/vs-spaces/). # Platform footprint > The measured environmental cost of running the platform — energy, emissions and AI usage. **Platform Footprint** publishes the environmental cost of operating the platform: energy consumed, CO₂ emitted, and the proportion attributable to AI.  The platform footprint — energy, CO2 and AI usage[Open `/footprint` in the app](https://ngostack.org/footprint) ## What it reports [Section titled “What it reports”](#what-it-reports) | | | | ----------------- | ----------------------------------------- | | **This month** | CO₂ emitted and energy used | | **Annual** | The same figures, cumulative | | **AI usage** | Calls made and tokens consumed this month | | **Live activity** | Current CO₂, watt-hours and average CPU | ## Why it is documented [Section titled “Why it is documented”](#why-it-is-documented) **The figures are measured, not offset.** They are drawn from infrastructure telemetry — energy, CPU and model usage — rather than from a purchased claim. This makes them verifiable. **AI usage is reported separately.** Each AI feature — autofill when posting, receipt scanning, funder briefs, generated reports — contributes to the total shown here, so the cost of those features can be assessed directly. The page is public and may be linked to by anyone evaluating the platform. [Platform Footprint](https://ngostack.org/footprint)Dashboard → Platform Footprint # Words the platform uses > The fixed value sets used by the platform — types, statuses, roles and visibility. Several fields accept only a fixed set of values. This page lists them for reference when a term is encountered in the interface, in an export, or in the API. The values below are as the platform stores them. The interface generally displays a formatted label — `on_hold` is shown as “On hold” — while exports, filters and the API use the stored value. ### Opportunity types What kind of thing an opportunity is. Chosen when it is posted. skill service volunteering funding event course collaboration mentorship other ### Opportunity status Where an opportunity is in its life. Set by the poster, except \`expired\`. draft active fulfilled expired closed ### Compensation How, or whether, an opportunity pays. volunteer paid funding barter unspecified ### Opportunity visibility Who can see an opportunity: everyone, or only your network. public network ### Connection status Where a connection request stands. pending accepted declined completed ### Knowledge entry types What kind of knowledge entry something is. article case-study best-practice resource ### Project status Where a project is in its life. planning active on\_hold completed abandoned ### Milestone status Where a milestone stands. planned active completed cancelled Generated, with one known limitation The values are read from the platform’s own API description — the full internal description, not the narrower [API reference](/developers/api/) published on this site. Only the headings and one-line explanations are written by hand. A set that disappears does not silently empty this page: regeneration fails and reports which vocabulary is missing. **The limitation:** this reflects what the API *describes*, which can lag what the platform *implements*. A value present in the code but absent from the description will not appear here. If you encounter a value in the interface that is not listed, please report it rather than assuming the value is incorrect. # Your account and your data > Exporting the data the platform holds about you, and what account deletion does. This screen covers two operations: exporting your data, and closing the account.  Exporting your data, and deleting the account[Open `/a/settings/account` in the app](https://ngostack.org/a/settings/account) ## Exporting your data [Section titled “Exporting your data”](#exporting-your-data) You can request a copy of the data the platform holds about you. It is produced as a **`.zip` containing one JSON file per area, plus a README** describing each file. Four properties apply: **The export contains your own records, not everything visible to you.** Content authored by other members is not included. **Secrets are excluded.** OAuth tokens, token hashes and device push tokens are deliberately omitted. **The download link is private and time-limited.** The file is stored privately and delivered through an expiring link rather than a public URL. If the link has expired, request the export again. **Preparation runs in the background.** You do not need to remain on the page. ## Deleting your account [Section titled “Deleting your account”](#deleting-your-account) Deletion is erasure rather than deactivation, and proceeds in two phases. ### Immediately [Section titled “Immediately”](#immediately) * **Access ends.** Sessions are revoked, the sign-in account is deleted, and API and connector access is withdrawn immediately rather than expiring. * **Personal details are scrubbed from the user record.** This also releases the email address and profile URL for reuse. * **Any subscription is terminated.** * **A data export is sent automatically**, to the email address captured at the time of the request. This ensures the export still reaches you after your details have been scrubbed. ### After thirty days [Section titled “After thirty days”](#after-thirty-days) The remaining record is hard-deleted. Shared content you authored is **anonymised** rather than removed, so that discussions involving other members remain intact while ceasing to be attributable to you. ### Sole administrators [Section titled “Sole administrators”](#sole-administrators) If you are the **sole** administrator, owner or coordinator of an organisation, project or workspace, deletion does not leave it without one. The platform **promotes a replacement**; where there is no one to promote, **that organisation, project or workspace is deleted as well**. Confirm this before requesting deletion. If something you created should outlive the account, add a second administrator to it first. [Account](https://ngostack.org/a/settings/account)Settings → Account # Pricing and billing > What each plan costs, the reduced rates for non-profits, and how trials work. All prices are in euros and exclude any applicable tax. Monthly and yearly billing are both available; yearly billing is charged at a lower effective rate. For the features included in each plan, see [What your plan includes](/start/plans/). ## Solo [Section titled “Solo”](#solo) **€9** a month, or **€84** a year — which works out at **€7** a month. First-time subscribers get a **30-day** trial — see [how trials work](#how-trials-work). Solo covers individual work: Unlimited in practice workspaces, 5 GB of storage, and the funding features. ## Org [Section titled “Org”](#org) The Org trial is up to **60-day**, twice the Solo trial, to allow time to set up an organisation, add members and run an initial project. The qualification “up to” is significant — see below. Org pricing also **varies by the country the organisation operates in**: | Rate | Monthly | Yearly | Yearly saves | | --------------------------------- | ------- | ------ | ------------ | | Standard | €99 | €999 | €189 | | NGO — high-income country | €49 | €490 | €98 | | NGO — upper-middle-income country | €29 | €290 | €58 | | NGO — lower-middle-income country | €19 | €190 | €38 | | NGO — low-income country | €12 | €120 | €24 | The reduced rates are for non-profit organisations, banded by the income classification of the country of operation. They are not a discount code or a negotiated rate; they are the standard price for organisations that qualify. Request verification before subscribing The band is applied at checkout automatically, but only once it has been assigned to the organisation — which happens when **verification is approved**, derived from the country. Subscribing beforehand means there is no band to apply at checkout, and the standard **€99** is charged. This is not permanent: when approval is granted the reduced rate is applied to the existing subscription. Only invoices raised before approval remain at the standard rate, and they are not refunded. See [the recommended sequence](/start/plans/).  Your plan, and where the trial and payment method are managed[Open `/a/settings/billing` in the app](https://ngostack.org/a/settings/billing) ## How trials work [Section titled “How trials work”](#how-trials-work) **Trial days are drawn from a single shared budget of 60 days, not a separate allowance per plan.** The figure quoted for each plan is the maximum for a first subscription. The trial granted is that figure or the remainder of the 60-day budget, whichever is smaller. Taking the **30-day** Solo trial and later moving to Org therefore yields the remainder rather than a further **60-day**. Subscribing directly to Org grants the full **60-day**. The remainder is intentional: it leaves an organisation arriving from a Solo trial time to complete verification and have its pricing band assigned before the first invoice. **The trial does not reset per plan.** This differs from the common convention and is a frequent source of confusion. ## What happens when a trial ends [Section titled “What happens when a trial ends”](#what-happens-when-a-trial-ends) **Without a payment method the trial cancels rather than converting.** The account reverts to Free, no charge is made and no invoice is raised. Add a payment method before the trial ends to continue on the plan. With a payment method, the subscription converts at the price your checkout was set up with. For **Org**, that includes the reduced non-profit rate — applied as a discount on the subscription, which Stripe starts charging once the trial ends. **Solo has no bands**, so it converts at the standard rate either way. If your organisation’s verification is approved *during* the trial, the discount is applied to the subscription you already have, so you still convert at the reduced rate. ## What is on the billing screen [Section titled “What is on the billing screen”](#what-is-on-the-billing-screen) Three tabs: **Plan** (your current subscription and renewal date), **Usage** (what you have consumed against your allowances) and **Invoices**. **Org access may be held by another organisation.** Where Org access derives from an organisation you belong to rather than one you pay for, the screen states this and identifies that organisation. Billing is managed where the subscription is held; switch to that organisation to make changes. ## Changing or cancelling [Section titled “Changing or cancelling”](#changing-or-cancelling) Billing is managed in **Settings → Billing**, and upgrades through **Upgrade**. Both require an authenticated session and are therefore performed in the app. Prices are generated, not transcribed Every figure above is read from the platform’s own configuration when this page is built, so a price change is reflected here automatically. No second copy of the price list is maintained. [Billing](https://ngostack.org/a/settings/billing)Settings → Billing # Integrations > API tokens for AI agents, outbound webhooks, and connected social accounts. **Settings → Integrations** has three tabs — **Access Tokens**, **Webhooks** and **Social** — which are gated on different plans: | | | | ------------------ | --------- | | Access tokens | Solo plan | | Outbound webhooks | Org plan | | Social connections | Org plan |  Access tokens, webhooks and social connections[Open `/a/settings/integrations` in the app](https://ngostack.org/a/settings/integrations) ## Access tokens [Section titled “Access tokens”](#access-tokens) A token allows an external client to act on your behalf — typically an **AI agent over MCP**, but also the curator browser extension or custom scripts. Two properties distinguish a token from a password: **Scopes.** A token carries only the permissions granted to it: reading workspaces, reading or writing wiki spaces, reading projects, submitting to ingestion. Over MCP, a tool outside the token’s scopes **is not listed at all** rather than listed and refused. The full list is in [the MCP scope table](/developers/mcp/#scope-summary). **A resource filter.** A token can be restricted to specific resources rather than to everything its scopes would otherwise permit, and the filter can be amended after the token has been issued. **Revocation is immediate.** A token that cannot be accounted for should be revoked rather than investigated; issuing a replacement has no cost. Certain scopes require an elevated role before a token carrying them can be created. A scope absent from the list indicates a missing role rather than a fault. The token is displayed once Copy it at the point of creation. It cannot be retrieved afterwards; a lost token must be replaced. ## Webhooks [Section titled “Webhooks”](#webhooks) An organisation can register **outbound webhook endpoints**. The platform calls the registered URL when an event occurs, removing the need to poll. Endpoints can be created, edited and deleted, and each can be sent a **test ping**. Sending one is recommended before relying on an endpoint: a failed delivery produces no visible signal, which is indistinguishable from no event having occurred. ## Social [Section titled “Social”](#social) Connected social accounts, used for cross-posting. Accounts are connected and disconnected here. [Integrations](https://ngostack.org/a/settings/integrations)Settings → Integrations # Notifications and email > Which alerts you can receive, how often, and where to change them. Notification settings are in **Settings → Notifications**, arranged in three groups: **Email & Alerts** for your own activity, **Organization Notifications** for administrators, and **Privacy**. ## Email frequency [Section titled “Email frequency”](#email-frequency) **Email digest frequency** controls batching, and has three settings: | | | | ---------- | -------------------------------------------------------- | | **Daily** | One email a day collecting everything since the last one | | **Weekly** | One email a week | | **Never** | No digest email. In-app notifications still appear | “Never” disables the *digest email* only; in-app notifications continue to appear. Weekly reduces volume without disabling notification entirely. ## Your alerts [Section titled “Your alerts”](#your-alerts) Each of these can be turned on or off independently of the digest frequency. | Alert | You get it for | Needs | | ---------------------- | ------------------------------------------- | --------- | | **Match alerts** | New matches being found | — | | **Connection alerts** | Connection requests and updates | — | | **Opportunity alerts** | New opportunities | Solo plan | | **Workspace alerts** | Assignments, contributions and due dates | — | | **Event reminders** | Upcoming events, in your digest email | — | | **Project alerts** | Updates published on projects you belong to | Org plan |  Notification settings[Open `/a/settings/notifications` in the app](https://ngostack.org/a/settings/notifications) **Switches for features not included in the current plan are hidden rather than disabled**, so the page is shorter on lower plans. Two alerts are plan-dependent: * **Opportunity alerts** require Solo plan or above. * **Project alerts** require Org plan, and are therefore absent on Solo as well as on Free. The remaining alerts are available on every plan. ## Organisation alerts [Section titled “Organisation alerts”](#organisation-alerts) Administrators of an organisation see a second group: | Alert | You get it for | | ----------------------- | -------------------------------------------- | | **Join request alerts** | Someone asking to join the organisation | | **Connection alerts** | Connection requests sent to the organisation | The organisation’s connection alerts are independent of your personal ones. The two switches share a name but are separate settings; changing one does not affect the other. **Member activity digest** is in the same group but is a **frequency** rather than a switch, with its own Daily / Weekly / Never setting independent of the email digest frequency above. The two can be set differently, or either can be disabled while the other remains active. ## Privacy [Section titled “Privacy”](#privacy) One privacy control is on this page rather than under Account: **Usage analytics** — when enabled, page views and interactions are recorded to inform platform development. It is disabled here. [Notifications](https://ngostack.org/a/settings/notifications)Settings → Notifications # Dates, times and display > Regional formatting — date format and time zone, applied to every date on the platform. **Settings → Preferences** holds regional formatting. Every deadline, milestone due date and report period on the platform is rendered using these settings.  Regional formatting — the date format every deadline is rendered through[Open `/a/settings/preferences` in the app](https://ngostack.org/a/settings/preferences) ## Date format [Section titled “Date format”](#date-format) Seven formats are available, named for the convention rather than for a country: | | | | ----------------------------- | ------------ | | English (UK) | `DD/MM/YYYY` | | English (US) | `MM/DD/YYYY` | | German | `DD.MM.YYYY` | | French · Spanish · Portuguese | `DD/MM/YYYY` | | **ISO 8601** | `YYYY-MM-DD` | **ISO 8601 is recommended for cross-border work.** `03/04/2026` denotes two different dates depending on the reader’s convention. `2026-04-03` is unambiguous in all locales and sorts correctly as text. ## Time zone [Section titled “Time zone”](#time-zone) A full IANA time zone list. This determines when a day ends for the purpose of deadlines, and should be set explicitly if you travel or if your organisation operates in a different zone. [Preferences](https://ngostack.org/a/settings/preferences)Settings → Preferences # Wiki databases > Structured records inside a space — fifteen column types, and the four that make it more than a spreadsheet. Your own space is Solo plan. A space can hold structured data in addition to prose: a table with typed columns, appropriate where a list has outgrown a bulleted format.  A database in a wiki space — typed columns, rows, and the view bar[Open `/s/me` in the app](https://ngostack.org/s/me) **Databases open as a panel over the space** rather than as a separate page. The database icon in the page toolbar opens the panel, and the back arrow returns to the list. Fifteen column types are available. The final four distinguish a database from a spreadsheet: | | | | ---------- | --------------------------------------------------- | | **Basic** | text, long text, number, date, checkbox, URL, email | | **Choice** | select, multi-select, status | | **People** | person | | **Linked** | **relation**, **rollup**, **lookup**, **formula** | A **relation** links a row to rows in another database. A **lookup** retrieves a value across that link, a **rollup** aggregates the linked rows, and a **formula** computes from the row itself. Together they allow a database to remain accurate without duplicating values. Rows can also open as pages, so a record can carry its own written page rather than being confined to a cell. ### Building a database [Section titled “Building a database”](#building-a-database) Rows can be created, edited and deleted, and any row can be opened as a page. Columns are typed on creation, and a column’s type can be changed subsequently, so a field that began as free text can become a fixed set of choices once its vocabulary is established. **In the table view, rows and columns are reordered by dragging.** Hovering over a row displays its handle in the margin **to the left of the table**, level with that row. Dragging the handle moves the row; selecting it opens that row’s actions. The row’s grip and ⋮ menu remain at the end of the row. A column’s grip is in its header. Rows can be dragged only while the table is in **manual order**. Once a sort or grouping is applied the order is determined by that, and the handle is not offered. Dragging a column moves it within that view alone where the view carries its own column order, and across the whole database otherwise. Column widths are dragged from the edge of a header and are retained per view. The row handle’s menu also **moves a row one position up or down** and **inserts a new row directly above or below** it. These are the same positional edits as dragging, for use where the table is long enough to make dragging impractical. They are subject to the same manual-order condition. Relations warrant planning in advance: they link to another database, and lookups and rollups read across that link. Establishing the relation correctly allows the derived columns to follow; adding it later requires re-entering values already held. [Your space](https://ngostack.org/s/me)Spaces # Spaces and the wiki > Where written knowledge lives — pages, databases, files, and what each kind of space can hold. Your own space is Solo plan. A **space** is a wiki comprising pages of written knowledge, together with databases and files. It holds material with a longer lifespan than a task: methods, policies, and maintained lists. Each owner has exactly one space, and there are three owner types: a member, an organisation, or a workspace. That constraint and its rationale are documented in [Workspaces and spaces](/workspaces/vs-spaces/). ## Pages [Section titled “Pages”](#pages) Pages are the primary content of a space. Three properties distinguish them from a folder of documents: **Version history and restoration.** A page retains previous versions, and an earlier version can be restored. Editing another member’s work is therefore recoverable rather than destructive, which is what makes a shared page safe to correct. **Backlinks.** A page can display the records that link to it, including workspace deliverables and database rows. A method page therefore accumulates a record of the work that relied on it. **Resolvable comments.** A comment thread can be closed once addressed, so a page under discussion does not accumulate permanent annotations.  A page in an organisation space, with the page tree beside it[Open `/s/me` in the app](https://ngostack.org/s/me) ### Who can edit a page [Section titled “Who can edit a page”](#who-can-edit-a-page) Pages start **private**, and can be set to `org` or `public`. | Where | Who may edit | | -------------------------------------- | -------------------------------------------- | | Your **personal** space | Only you | | An **organisation or workspace** space | Anyone in it who can already *read* the page | | A page still marked **private** | Its author alone, wherever it lives | In a team space, a shared page can therefore be corrected by colleagues. This is by design: a wiki that cannot be corrected becomes stale. Visibility is the controlling setting — a page not ready for editing should remain private. History is more restricted than editing, by design Version history and restoration remain **creator-or-admin**, even where any member may edit. A snapshot contains the page’s entire former content, including material held while the page was private. Granting every member access to history would expose precisely what the visibility setting was protecting. ### Working with pages [Section titled “Working with pages”](#working-with-pages) Pages **open in tabs** along the top, so position is retained when moving between them. The editor **saves continuously**; the header displays *Saved* and a live word count, and there is no save control. **New page** creates a page immediately, with no dialog. A page begins as *Untitled* and saves as it is typed. `⌘N` performs the same action. Pages **nest**: any page can take child pages, so a space becomes a tree rather than a flat list. Each page’s menu carries the rest: | | | | ------------------------- | ------------------------------------------------------------------- | | **Rename** | Titles are editable at any time | | **Duplicate** | Copy a page, structure and all — the fastest way to make a template | | **Copy link** | A normal URL for people | | **Copy page ID** | The raw identifier | | **Copy MCP resource URI** | The address an **AI agent** reads this page at | | **Delete** | Removes the page | **“Copy MCP resource URI” provides the address at which an agent connected over [MCP](/developers/mcp/) can read that specific page.** A runbook written for people can therefore be supplied to an agent without exporting or duplicating it. ### The page toolbar [Section titled “The page toolbar”](#the-page-toolbar) The icons along the top of a page carry no visible labels. They are, in order: | | | | ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | **Share** | Publish the page to a link, and manage who can open it | | **Search** | Find pages across the space | | **Backlinks** | Every page that links *to* this one | | **Comments** | Open the comment thread on this page | | **Page history** | Earlier versions, and restoring one | | **Export** | Download the page | | **Trash** | Deleted pages, and restoring them | | Width toggle | Switches the page between standard and full width — the label reads *Full width* or *Standard width* depending on which it will switch you to | | **Google Drive** | Insert a file from a connected Drive | ### What you can put in a page [Section titled “What you can put in a page”](#what-you-can-put-in-a-page) Typing `/` opens the block menu, which offers twenty block types: | | | | ------------------------------------------- | ----------------------------------------------------------------------------- | | **Text** | Paragraph, Heading 1–3, bullet and numbered lists, code block, quote, divider | | **Callout** | A highlighted note or tip | | **Toggle** | A collapsible section, for detail that would otherwise obscure the main point | | **Table of Contents** | Generated from the page’s headings, and therefore always current | | **Table** | Insert one, or import it | | **Page** | A sub-page *within* this page, by which a space acquires a hierarchy | | **Image / File**, **File upload** | Images embed; anything else becomes a download link | | **Google Drive** | Embed a file from Drive rather than uploading a copy | | **Database** | A table, board or calendar embedded in the page | | **Deliverables / Tasks**, **Contributions** | Workspace lists, embedded live | **The last two appear only in a workspace’s own space**, as there is no workspace for them to read elsewhere. **Google Drive embeds rather than uploads.** The file remains in Drive and the page references it, so a single copy exists and Drive permissions continue to govern access rather than the space’s. ### Editing a table [Section titled “Editing a table”](#editing-a-table) Placing the cursor in a cell displays handles: one at the **left of each row** and one at the **top of each column**. Selecting a handle opens its menu. Handles are shown only to members who may edit the page. | | | | ------------------------------------------------- | ------------------------------------------------------- | | **Move up / down**, **Move left / right** | Reorder a row or a column, contents and all | | **Insert above / below**, **Insert left / right** | A new row or column *at that position* — not at the end | | **Delete row**, **Delete column** | Removes it, and everything in it | **Rows are moved by dragging their handle.** An indicator shows the destination. Rows are the only draggable element; columns are moved through their menu. The dashed controls at the outer edges — below the last row and to the right of the last column — append one. **Tab** from the final cell does the same, stepping through cells and starting a new row when none remain. `Shift`+`Tab` steps backwards. **A header row remains the first row.** Where a table has one, it cannot be dragged, nothing can be inserted above it, and no row can be moved past it. **A table always retains one row and one column.** *Delete* is removed from the menu when only one remains rather than being present and inactive. Selecting all cells and pressing Backspace deletes the table With the entire table selected, `Backspace` and `Delete` remove the **table** rather than its contents. To clear contents, select only the cells to be emptied. ## Databases [Section titled “Databases”](#databases) A space can hold structured data in addition to prose: tables with typed columns, relations, rollups and formulas. These are documented separately in **[Wiki databases](/spaces/databases/)**. ## Files [Section titled “Files”](#files) Spaces hold images and documents against a shared quota. The limits depend on **the space’s owner type**, not on the member’s plan: | Owner | Total storage | Max image | Max file | | ---------------- | ------------- | --------- | -------- | | **Personal** | 100 MB | 5 MB | 10 MB | | **Workspace** | 250 MB | 10 MB | 25 MB | | **Organisation** | 500 MB | 10 MB | 25 MB | Images must be **JPEG, PNG or WebP**. Documents must be **PDF, Word, Excel, PowerPoint, plain text or CSV**. No other formats are accepted. **The quota is shared between images and documents**, so image-heavy spaces have proportionally less capacity for documents. Where a personal space approaches its limit, the material generally belongs in an organisation or workspace space, which have larger quotas and wider audiences. [Your space](https://ngostack.org/s/me)Spaces # Getting started > The recommended order for your first week, and the reason for that order. The following sequence is recommended for a new account. Each step supplies input to the next, and completing them out of order is the most common reason the platform appears inactive. 1. **Complete your profile.** The profile is the primary input to matching and the means by which other members find you. Time invested here determines the quality of everything that follows. → [Set up your profile](/start/profile/) 2. **Complete What I Need and What I Can Offer.** These are the two most frequently omitted fields, and the two that pair across members: your needs are matched against other members’ offers rather than their needs. 3. **Review what your plan includes.** On Free you can participate fully in work started by others but cannot start your own, and several modules are unavailable. Establishing this early avoids the most common initial confusion. → [What your plan includes](/start/plans/) 4. **Review the network.** The [Atlas](/start/atlas/) shows where members are located. Member density by country provides context for the size of a match list. 5. **Connect with several members, and record outcomes.** Marking a connection *completed* with an outcome is the one matching input determined by activity rather than by profile content. → [Finding and connecting](/network/connect/) 6. **Search for work.** Opportunities, matches and suggestions read the profile, which is why this step comes last. → [Finding opportunities](/opportunities/finding/) ## Common causes of a thin match list [Section titled “Common causes of a thin match list”](#common-causes-of-a-thin-match-list) Three factors account for most reports that matching is not working: * **Empty specialty, needs or offers.** These are the highest-weighted fields and the most frequently omitted. * **Too many interests.** Overlap is scored as shared terms ÷ combined terms, so listing a large number of interests weakens every match, including strong ones. * **Only one side has completed a field.** A field is scored only when both members have completed it, so two well-suited members can score zero by describing themselves in different fields. The full mechanics, including the weights, are in [How matching works](/network/matching/). [Your profile](https://ngostack.org/a/settings/profile)Settings → My Profile # The Atlas > The map of the network — members, opportunities and consortium calls by country. The **Atlas** presents the network as a map: member locations, opportunity locations, and open consortium calls. Selecting a country displays its contents.  The public atlas[Open `/atlas` in the app](https://ngostack.org/atlas) ## The three layers [Section titled “The three layers”](#the-three-layers) The map displays one layer at a time. Each answers a different question: | Layer | Shows | | ----------------- | --------------------------------------- | | **Members** | Member density and locations by country | | **Opportunities** | Where open opportunities are | | **Consortium** | Where consortium calls are open | A ranked country list accompanies the active layer, so the members in a given country can be reached in two selections rather than by search. ## Uses [Section titled “Uses”](#uses) **Assessing member density in a given country.** A country with a small number of members presents different prospects from one with a large number, for partnership, consortium bids, and judging whether a call is worth pursuing. **Interpreting a thin match list.** Distance accounts for 10% of a match score and is [banded in kilometres](/network/matching/#distance), so a sparse local network is a constraint rather than a fault in matching. **Public visibility.** The Atlas is a public-facing view of the network. Members without a location set do not appear on it. [Atlas](https://ngostack.org/a/atlas)Dashboard → Atlas # Your dashboard > What the home screen reports, including the verification prompt and the network figures. **Home** is the screen shown after signing in. It reports status rather than providing a workspace: items requiring attention, and the size of the network.  Your dashboard after signing in[Open `/a/dashboard` in the app](https://ngostack.org/a/dashboard) ## The verification prompt [Section titled “The verification prompt”](#the-verification-prompt) If an organisation is unverified, the dashboard reports this and requests completion of its profile. This should be actioned before subscribing. Verification assigns the non-profit pricing band to the organisation, and [checkout applies the band automatically once it is assigned](/start/plans/#non-profit-pricing-request-verification-before-subscribing). Subscribing beforehand means there is no band to apply and the standard rate is charged. The band is applied to the existing subscription when approval is granted, so only invoices raised before approval remain at the standard rate. ## The network figures [Section titled “The network figures”](#the-network-figures) The dashboard reports network-wide totals rather than individual activity: the number of members, the number of countries represented, the number of currently active opportunities and their distribution by type, and the number of connections made across the platform. These figures provide context. A total such as “1,175 active opportunities” indicates what is available to be found, and is a prompt to review your [matches](/opportunities/finding/) and profile rather than a measure of your own activity. [Home](https://ngostack.org/a/dashboard)Dashboard → Home # What your plan includes > The difference between Free, Solo and Org — and what changes when you upgrade. There are three plans. The difference between Solo and Org is not one of scale: Org enables a different category of work. |   | Free | Solo€9/mo30-day trial | Org€99/mo60-day trial | | ------------------------- | ------------ | --------------------- | --------------------- | | Workspaces you can create | Not included | Unlimited in practice | Unlimited in practice | | Wiki databases | Not included | Unlimited in practice | Unlimited in practice | | Projects | Not included | Not included | Unlimited in practice | | Proposals | Not included | Not included | Unlimited in practice | | Briefs | Not included | Not included | Unlimited in practice | | File storage | 100 MB | 5 GB | 50 GB | | AI usage per month | Not included | 500,000 | 5,000,000 | | API tokens | Not included | 10 | 25 | ## Free: participation without hosting [Section titled “Free: participation without hosting”](#free-participation-without-hosting) The defining characteristic of the Free plan is not a quota but a **boundary**: you can be invited into work started by others and participate fully, but you cannot start your own. On Free the following are available: | Open on Free | Needs a plan | | ----------------------------------------------- | ----------------------------------------------- | | **Home**, with a teaser of what is being posted | **Opportunities** — the whole module, Solo plan | | **Atlas** | **My Matches** in Network, Solo plan | | **Network → Members** and **Connections** | **Spaces**, Solo plan | | **Workspaces you were invited to** — in full | **Projects** and **Funding**, Org plan | | **Settings**, including your profile | Creating a workspace of your own | **Workspaces are deliberately never locked.** Being invited and contributing is the intended use of the Free plan: you can open a workspace, submit work to a deliverable, comment and approve. Only workspace *creation* is gated. **Locked modules remain visible.** They stay in the navigation with a padlock and open an upgrade prompt when selected, so the full feature set is always visible. This explains the common case where an invited member finds everything works until they attempt to create something new. ## Solo: individual work [Section titled “Solo: individual work”](#solo-individual-work) Solo is intended for an individual running their own work. It provides Unlimited in practice workspaces, 5 GB of file storage, and 500,000 AI tokens per month. It also enables the funding features: Solo plan and above can post opportunities, and Solo plan provides matching against them. Solo does **not** include the delivery features. Projects, proposals and briefs all require Org plan. ## Org: delivery as well as discovery [Section titled “Org: delivery as well as discovery”](#org-delivery-as-well-as-discovery) Org adds three capabilities not present on Solo: | | Needs | | --------------------------------------------------- | -------- | | Projects — plan, budget and report on delivery | Org plan | | The proposal engine — draft and refine applications | Org plan | | Funder intelligence — research who funds what | Org plan | Storage rises to 50 GB and AI usage to 5,000,000 tokens a month. ## Non-profit pricing: request verification before subscribing [Section titled “Non-profit pricing: request verification before subscribing”](#non-profit-pricing-request-verification-before-subscribing) Org is priced on a sliding scale determined by the income band of the organisation’s country. The difference is substantial: the lowest band is a fraction of the standard rate. The band is assigned when the organisation’s **verification is approved**, derived from its country’s income group. The recommended order is: 1. Create the organisation with its country set. 2. [Request verification](/organization/manage/#requesting-it), and wait for it to be approved. 3. Subscribe. The reduced rate is applied automatically at checkout. **Subscribing before approval is not irreversible.** Checkout has no band to apply at that point, but when approval is granted the reduced rate is applied to the **existing** subscription rather than only to a subsequent one. The same applies where an administrator assigns the tier manually. The exposure is limited to invoices raised before approval, which remain at the standard rate and are neither refunded nor back-dated. If approval is granted during the trial period, no charge has been raised and the subscription converts at the reduced rate. The recommended order therefore avoids one or two standard-rate invoices; it is not a condition of receiving the discount. A band is auto-assigned only where one is not already set, so an organisation whose tier was assigned manually retains it. Figures on this page are generated Every figure above is read from the platform itself at build time — prices and trial lengths from the live API, limits from the code that enforces them. If a limit changes, this page changes with it. Nobody has to remember to edit it. [Billing](https://ngostack.org/a/settings/billing)Settings → Billing # Set up your profile > The profile is the platform's primary matching input — including the fields most often left empty. The profile is the input matching reads, and what other members see when deciding whether to connect. There is no separate mechanism for posting an offer, so **the profile serves that purpose**. An incomplete profile is the most common reason a member is not found. [Profile settings](https://ngostack.org/a/settings/profile)Settings → Profile ## Importing from a website [Section titled “Importing from a website”](#importing-from-a-website) Enter a URL in **Profile URL** and select **Import**. Where a personal site, organisation biography or public profile exists, the platform reads it and populates the fields it can. The URL must begin with `http://` or `https://` and can be **up to 2048 characters**. Review and correct the result. As with opportunity autofill, the output is a draft derived from a single page and should be treated as such.  The profile fields matching reads — specialty, needs, offers, interests, match tags[Open `/a/settings/profile` in the app](https://ngostack.org/a/settings/profile) 1. **Name and photo.** First and last name are **up to 100 characters** each. 2. **Choose your profile URL.** This is the address people share. **2–60 characters** — Lower case, digits and hyphens. It cannot start or end with a hyphen. 3. **Keep the bio brief.** It is **up to 160 characters**. A one-line introduction rather than a biography; a character counter is displayed below the field. 4. **Set your intent.** One of *Explore the network*, *Launch an initiative*, *Represent my organization*, or *Manage a community*. This states your purpose on the platform. 5. **State your specialty.** One line describing your work. This is compared directly against other members’ specialties, so a specific term such as “water and sanitation engineering” performs better than a general one such as “consultant”. 6. **Complete What I Need and What I Can Offer.** These are the two most frequently omitted fields. As there is no separate mechanism for posting an offer, this is where an offer is recorded. They are matched **directionally**: your *needs* are compared against other members’ *offers*, and your *offers* against their needs. This is the one part of matching that pairs complementary entries rather than similar ones — “I need a grant writer” matches “I can write grants”. Both fields are free text and are read as sentences. 7. **Add interests as tags.** Select existing tags where possible. The tag vocabulary is shared with opportunities, so `climate-justice` on a profile matches `climate-justice` on a call for proposals. 8. **Add Match Tags.** A separate field from Interests, weighted slightly lower but still significant. Interests describe subjects of concern; match tags are the themes you wish to be found for. Completing only one of the two leaves a comparison unused — [see how the parts are weighted](/network/matching/). 9. **Set your location.** Search for a city or use the current location. Distance acts as a tiebreaker rather than a filter, so an approximate city is sufficient. 10. **Save.** Fewer interests produce stronger matches Overlap is scored as *shared terms ÷ combined terms*. Listing a large number of interests to increase coverage weakens **every** match, including strong ones. A small number of interests you actively work on outperforms a long list. The same applies to match tags. See [How matching works](/network/matching/). ## Controlling what is visible [Section titled “Controlling what is visible”](#controlling-what-is-visible) The **Visibility** tab carries a single switch — *Show my profile publicly*. It governs your logged-out profile page and whether you appear in the public directory and map. It is not a per-field control, and it does not apply to other members: signed-in members see the same fixed set of profile fields either way, and you stay listed in Network → Members regardless. **To keep something from other members, leave the field empty.** The trade is real — an empty field is also one that matching cannot use. ## Putting your profile elsewhere [Section titled “Putting your profile elsewhere”](#putting-your-profile-elsewhere) The profile page provides a **URL**, an **iframe embed** and a **badge**, each with a copy button. The embed is suitable for an organisation’s team page; the badge for an email signature or personal site. ## If matching is not producing results [Section titled “If matching is not producing results”](#if-matching-is-not-producing-results) In order of likelihood: 1. **Specialty, needs and offers are empty.** These carry the greatest weight and are the most frequently omitted. 2. **Too many interests.** As above, breadth lowers every score. 3. **Tags no other member uses.** A precise tag used by no one else produces no overlap; a broader tag shared with others performs better. 4. **No location.** This accounts for 10% of the score and is rarely the sole cause. Matches recompute within approximately thirty seconds of saving, so a change can be tested directly. # Create a workspace > Three modes that decide how the work runs — pick before you invite anyone. Creating a workspace requires Solo plan. On the Free plan a member can be invited into a workspace and participate fully, but cannot create one. [Workspaces](https://ngostack.org/w)Workspaces in the sidebar  Your workspaces. Empty until you create or are invited to one.[Open `/w` in the app](https://ngostack.org/w) ## Selecting the mode [Section titled “Selecting the mode”](#selecting-the-mode) The mode determines how work progresses through the workspace and should be decided before members are invited.  The three modes, named for what they mean rather than what they are called in the API.[Open `/w/` in the app](https://ngostack.org/w/) | Mode | What it means | Needs | | ------------------ | -------------------------------------------- | --------- | | **Task Board** | A kanban board with no contribution workflow | Solo plan | | **Equal Partners** | All participants shape the work jointly | Org plan | | **Led by One** | A single organisation sets direction | Org plan | **The mode cannot be changed after creation.** The settings screen states this: *“Collaboration mode is set when the workspace is created and cannot be changed.”* Every other workspace field is editable. **The modes are gated on different plans**, which the create dialog does not indicate at the point of selection. Task Board is available on Solo; the two cross-organisation modes require Org, and this is enforced on submission rather than on selection. **Task Board also differs in operation.** The other two modes run a contribution workflow in which deliverables are assigned, partners submit against them and a reviewer responds. Task Board provides a board without that workflow, and should not be selected where a review step is required. 1. **Enter a title** stating what the group is producing — for example “Wallacea grant application” rather than “Collaboration”. 2. **Add a one-line description.** Optional, and the first text an invited partner reads. 3. **Select the mode.** See above, and confirm the plan: cross-organisation modes are rejected on submission rather than disabled in the form. 4. **Set start and end dates.** Optional. A workspace is intended to be time-bounded and archived once its output is delivered. 5. **Create it.** ## Workspace contents [Section titled “Workspace contents”](#workspace-contents) | | | | ----------------- | --------------------------------------------------- | | **Deliverables** | The outputs being produced. Assign, submit, review. | | **Contributions** | What partners have submitted against them. | | **Files** | Shared files. | | **Wiki** | Pages for the group. | | **Members** | Who is in it, and their role. | | **Insights** | Activity across the workspace. | Deliverables and contributions are documented separately, including the six deliverable states, the four possible responses to a contribution, and the two methods of generating suggested deliverables: **[Deliverables and contributions](/workspaces/deliverables/)**. Roles, invitations, guest accounts and the switch controlling whether AI agents can reach the workspace are in **[Members and access](/workspaces/members/)**. ### Exporting the activity log [Section titled “Exporting the activity log”](#exporting-the-activity-log) A workspace’s **activity log exports as CSV** over a date range defaulting to the previous 90 days. It is an audit trail of actions and timestamps rather than the deliverables themselves, and is intended for evidencing that a collaboration took place. ### Workspace origins [Section titled “Workspace origins”](#workspace-origins) Not all workspaces are created directly. A workspace can originate from a **connection**, an **opportunity**, a **project** — where a milestone generates the workspace that delivers it — or as a **standalone**. A workspace that was not created directly will have one of these origins. A deliverable is an output, not a task “Module 3: Conflict Resolution” is a deliverable; “Write section 3” is not. The submit-and-review pipeline handles completed outputs, which is why it contains no sub-task concept. ## Settings [Section titled “Settings”](#settings) **More → Settings** has four tabs: **General**, **Storage**, **Tags** and **Access**. General holds the title, the **URL slug** — workspaces receive a readable address such as `/w/wallacea-grant-application` rather than an identifier — a description, and **start and end dates**. All are editable at any time. The collaboration mode is not. ## Archiving [Section titled “Archiving”](#archiving) Archiving is in the settings screen’s **Danger Zone**. Its effect is narrower than the term suggests: **the workspace becomes read-only. Members retain access but can no longer make changes.** It is neither a deletion nor a removal from view: every member who could previously see the workspace can still see and read all of its contents. It can be **unarchived** to active, and no content is lost. The same principle applies one level down, with one exception: | | | | ---------------- | --------------------------------------------------------------- | | **Deliverable** | **Archived** — hidden from the default list, and **restorable** | | **Contribution** | **Deleted**, and only a coordinator can | | **Attachment** | Deleted | The reversible action therefore applies to the containers, and the irreversible one to submitted material. Deleting a partner’s contribution is not an archive operation and can be performed only by a coordinator. Deliverables can also be **reordered**. The order determines how partners read the work. ## Workspace or project? [Section titled “Workspace or project?”](#workspace-or-project) A workspace is where work is produced; a project is the initiative. Neither contains the other, and a workspace can exist without a project. The distinguishing test: work produced **with members of other organisations** is a workspace; work planning what a single organisation is trying to achieve is a project. See [Project or workspace?](/projects/vs-workspaces/). Note that workspaces and *spaces* are distinct again, and scope in opposite directions: [Workspaces and spaces](/workspaces/vs-spaces/). # Deliverables and contributions > The unit of work in a workspace, the six states it moves through, and the four answers a submission can get. A **deliverable** is an output being produced. A **contribution** is a submission made against one. All workspace activity is organised around this pair.  A workspace: deliverables, contributions, files and its own wiki[Open `/w/` in the app](https://ngostack.org/w/) **File uploads require connected storage.** A workspace without a Google Drive connection displays a notice, and deliverables cannot accept file attachments until storage is configured in the workspace’s settings. Contributions can still be submitted as **text or a link**, so an unconnected workspace remains usable for everything except files. ## A deliverable is an output, not a task [Section titled “A deliverable is an output, not a task”](#a-deliverable-is-an-output-not-a-task) “Module 3: Conflict Resolution” is a deliverable; “Write section 3” is not. The submit-and-review pipeline handles completed outputs, which is why it contains no sub-task concept. Work breakdown below this level belongs in the partner’s own tooling. ## Adding deliverables [Section titled “Adding deliverables”](#adding-deliverables) Deliverables can be created manually, edited, and **reordered**. The order determines how partners read the work, so it should be set deliberately rather than left in creation order. Two further routes are available: **Suggested from the workspace’s origin.** A workspace created from an opportunity, a project or a connection can propose the deliverables that follow from it. **Suggested from an uploaded document.** Supplying the funder’s call or a partner agreement produces the deliverables that document implies. Both produce suggestions for acceptance or rejection rather than a finished plan. ## The six states [Section titled “The six states”](#the-six-states) **Draft → in progress → in review → approved → done → published.** The board displays five as columns — draft, in progress, in review, approved, published. A **List** view is available alongside the Kanban. Three of the states are readily conflated and have distinct meanings: | | | | ------------- | ---------------------------------- | | **Approved** | The reviewer’s verdict on the work | | **Done** | Work on the item is complete | | **Published** | The item has left the workspace | A deliverable may remain approved and unpublished for an extended period; this is not an error state. ## Contribution outcomes [Section titled “Contribution outcomes”](#contribution-outcomes) A contribution is submitted as a **file, text, or a link**. A link is a valid submission, so work held in another system does not need to be re-uploaded. | Outcome | Means | | ---------------------- | ----------------------------------------------------------- | | **Accepted** | Taken as it is | | **Revision requested** | Sent back with changes | | **Needs discussion** | Neither acceptance nor rejection; requires discussion first | | *(submitted)* | Awaiting review | **Needs discussion is frequently overlooked.** It exists to avoid a specific outcome: rejecting a contribution that required only clarification, which tends to disengage the partner. It allows a reviewer to avoid choosing between accepting uncertain work and returning it. **Deleting a contribution is permanent and restricted to coordinators.** Deliverables are *archived* and can be restored; submitted contributions cannot. [Workspaces](https://ngostack.org/w)Workspaces # Members and access > Three roles, invitations that work without an account, and the switch that decides whether AI agents can reach the workspace. Workspace membership, the permissions attached to each role, and the separate question of whether automated clients may access the workspace.  Workspace members and their roles[Open `/w/` in the app](https://ngostack.org/w/) ## Three roles [Section titled “Three roles”](#three-roles) | Role | Can | | --------------- | --------------------------------------- | | **Coordinator** | Full control of the workspace | | **Partner** | Submit contributions, view deliverables | | **Observer** | Read only | **Partner is the operational role**, and it is narrower than commonly assumed: a partner submits against deliverables rather than creating them. Where a partner organisation needs to shape the work as well as deliver it, [Equal Partners mode](/workspaces/create/) applies — the mode determines the scope of the role. ## Inviting people [Section titled “Inviting people”](#inviting-people) Members can be invited **in bulk** rather than individually. **An invitation does not require an existing account.** A recipient can accept as a **guest**, which is a limited account scoped to workspaces and projects. A new partner therefore requires only an email address rather than a full registration. Joining is deliberately available on the **Free** plan: the platform gates the creation of work rather than participation in it. See [what your plan includes](/start/plans/). ## External agent access [Section titled “External agent access”](#external-agent-access) A workspace carries an **external agent access** switch, set by the coordinator. This is the only per-resource control of its kind on the platform. Personal and organisation wikis have no equivalent; for those, narrowing the token is the only available restriction. A workspace can deny access regardless of what a member’s token otherwise permits. **Coordinators are also shown the workspace’s exposure.** The settings screen reports the number of **members** — not tokens — holding at least one active token that could reach the workspace. A member with three tokens is counted once, as the figure reports how many people have an agent able to reach the work rather than how many credentials exist. This figure is visible to coordinators only. [Workspaces](https://ngostack.org/w)Workspaces # Workspaces and spaces > Two similar-looking containers that scope in opposite directions. Workspaces and wiki spaces look alike in the interface and behave in opposite ways underneath. Confusion between the two is the most frequent subject of visibility-related support requests. This page states the distinction; other pages link here rather than restating it. ## Summary [Section titled “Summary”](#summary) | | Workspace | Wiki space | | --------------------------- | ------------------------------------- | ----------------------------- | | Owned by an organisation? | **No** — there is no owner-org at all | **Yes** — it has an owner | | Scoped by the org switcher? | **No** | **Yes** | | Scoped by | Mode: personal or shared | The organisation that owns it | ## A workspace has no owning organisation [Section titled “A workspace has no owning organisation”](#a-workspace-has-no-owning-organisation) A workspace is not owned by a single organisation; it is a location in which several organisations and individuals collaborate. Listing workspaces returns every membership held, across every organisation the member belongs to. This has a direct interface consequence: **the organisation switcher must not filter a workspace list.** Doing so implies a scoping the data model does not support, and would appear to filter by organisation while in fact hiding memberships arbitrarily. Workspaces are separated by **mode** instead: * **Personal** — task mode. Your own work. * **Shared** — collaborative and coordinated modes. Work with others. ## A wiki space does have an owner [Section titled “A wiki space does have an owner”](#a-wiki-space-does-have-an-owner) A wiki space carries an owner type and owner ID. Organisation scope therefore applies and should *follow* the member: switching organisation moves into that organisation’s spaces. There are **three** kinds of owner, not two: | Owner | The space belongs to | | ------------- | ------------------------------------------------------ | | **User** | You personally | | **Org** | An organisation you belong to | | **Workspace** | A workspace — so a collaboration can have its own wiki | The third owner type is why a workspace can hold a wiki without owning it in the sense an organisation does: the space is owned *by the workspace*, while the workspace itself has no owning organisation. ### One space per owner [Section titled “One space per owner”](#one-space-per-owner) Owner type and owner ID are unique in combination, with a consequence frequently reported as a fault: **each owner has exactly one space.** One personal space, one per organisation, one per workspace. A second space cannot be created for the same organisation. Where an organisation already has a space, no “new space” control is presented; the existing space is the one to use, and structure is created within it as pages. ## For client implementations [Section titled “For client implementations”](#for-client-implementations) Scope a space list by organisation and a workspace list by mode. An organisation switcher presented over a workspace list is a defect.