Team knowledge is not just a wiki. In Apexloop it can be connected to databases, records, views, emails, forms, chat, automations and print outputs. A good structure therefore doesn't just solve where to write text — it also addresses where decisions are made, where data is created and where the next work is triggered from.
The basic rule
Create separate places for three different types of information:
| Content type | Where it belongs | Example |
|---|---|---|
| Stable knowledge | Document page | Guide, process, sales methodology |
| Working data | Database and records | Task, company, invoice, project, campaign |
| Summary and decisions | View or dashboard | Pipeline, capacity, report, weekly plan |
When you put everything on one long page, the team ends up copying data manually. When you put everything into a grid, context gets lost. The best result comes from combining both: a page explains the process, a database holds the values, and views show the current state.
Workspace structure
At the top level, have only a few entry points. A user should be able to quickly recognise where to go for daily work.
Recommended structure:
- Team home page with priorities, links and dashboard.
- Area for customers, projects or the main process.
- Area for internal documentation and policies.
- Area for reports, print outputs and exports.
- Area for settings, dictionaries and administration.
Embed database components with the most-used views on the home page. People won't have to navigate to find their tasks, pending approvals or today's deadlines.
When to use a page and when a database
Use a document page when the primary value is explanation, text, context or a template. Use a database when you need to filter, assign, calculate, track deadlines, trigger automations or generate outputs.
Typical division:
- The purchasing process is a page; individual purchase requests are a database.
- Sales methodology is a page; companies, contacts and opportunities are a database.
- An invoice template is a document page; invoices and line items are a database.
- A newsletter brief is a link to a document page on the campaign record; segments and dates are fields.
If you often ask "what status is it in", "who owns it" or "how many do we have" about a piece of information, it probably belongs in a database.
Use the record as a context hub
A record detail should show everything a person needs to make a decision. For this you have properties, relations, view columns, a document page link, attachments, chat and email.
Example of a project detail:
- Core fields: name, status, customer, owner, deadline, budget.
- View columns: tasks, risks, invoices, files, emails.
- Formulas: hours worked, open blockers, remaining budget.
- Document page link: specification, meeting notes and project brief.
- Chat sidebar: project discussion directly in context.
- Buttons: create a report, send an update, create an invoice.
Such a detail replaces manually assembling information from documents, spreadsheets and chat.
Keep dictionaries as databases
Create statuses, priorities, order types, segments, product areas or loss reasons as standalone databases. Select and multiselect columns then reference them.
Advantages:
- Values can be described and annotated.
- Dictionaries can be filtered and extended without changing the main database structure.
- The same values can be used by forms, views, automations and reports.
- History and ownership remain visible just like for other records.
For statuses we recommend adding order, colour or group if you use them in kanban, reports or automations.
Design views around the work
A view is not just a different way of displaying a table. It is the way the team does specific work.
Use:
- Datagrid for precise data control and bulk work with columns.
- Kanban for pipeline, workflow and drag-and-drop between statuses.
- Calendar for deadlines, meetings, campaigns and due dates.
- Schedule for capacities and scheduling people.
- Timeline for long projects, releases and roadmaps.
- Chart for metrics, trends and aggregations.
- Gallery for visual content, templates or campaigns.
- Detail and group view for working in hierarchies, subgroups and subitems.
Name each important view after the question it answers. For example "What is awaiting approval", "Which projects are overdue" or "Newsletters to send this month".
Connect communication to work
Keep email, forms and chat with the records. A form can create a new row in a database, emails can be tracked and mapped to databases, attachments belong in file columns and chat on a page or record keeps the discussion in context.
Practical setup:
- A public form creates an enquiry or contact.
- Email attachments are saved to the relevant record.
- The HTML body of an email is stored in a database HTML column.
- An automation works with a followed email the same way as any other record.
- The document editor prepares content and the backend converts it to email-safe HTML.
This way communication does not become a parallel system. It becomes another layer on top of the same data.
Prepare print and export outputs
Design every recurring document as a template. A document page can contain placeholders, database views, QR codes, images, text blocks, media, dashboards and buttons.
Usage:
- Invoice: invoice record, line items via view column, QR payment and PDF.
- Proposal: customer, variants, amounts, terms and attachments.
- Project report: aggregations from tasks, timeline, charts and risks.
- Newsletter: document page link on the campaign record, scheduled send and HTML export.
Leave placeholders like {{customer}}, {{invoice_number}} or {{total_amount}} to be filled by automation. This way the team has one template but each output is generated from current data.
Set ownership and maintenance
Every important page or database should have an owner. The owner doesn't have to write everything themselves, but is responsible for making sure the structure makes sense and that outdated information doesn't stay visible.
Review regularly:
- Unused views and duplicate pages.
- Dictionaries with values that mean the same thing.
- Automations that change non-computed fields.
- Formulas that no longer reflect the current process.
- Archived records that should remain read-only.
- Permissions on sensitive columns.
Recommended first audit
After the first two weeks of use, review the workspace with the team:
- Which view do people open every day?
- Which field is often missing or filled in inconsistently?
- Which manual steps repeat and should be automated?
- Which information is still being handled outside records or pages?
- Which outputs does the team export or send to customers?
Use the answers for further model refinement. Apexloop is strongest when the structure evolves together with the team's work and every new part has a clear reason.