Help & Documentation

This page orients you on day one. For the full feature list see About inveazy (/about). For server setup see Installation & Docker.

What is inveazy?

inveazy is a multi-tenant business hub on a single installation. Each workspace (tenant) is an isolated company environment — own users, data, and enabled apps — sharing one database with row-level security.

Shipped modules today include CRM and project management; full supply chain (buy, stock, sell, ship); accounting with local GL, QuickBooks export, and Stripe; B2B web orders; hub apps (files, notifications, calendar, blog); and a workspace assistant with module-scoped AI. Planned modules are on Roadmap; shipped highlights are in Changelog.

Who should read what?

You are…	Start here
End user (sales, warehouse, PM)	Sign in → / hub launcher → open your module; use megamenus (CRM, SCM, PM, HUB)
TenantAdmin	Tenant Admin overview — workspaces, Integrations, branding
Admin	Admin menu overview — dashboards, users, roles
Executive / manager	Dashboard launcher (/dashboard) — CRM, PM, finance, SCM analytics
Operator / developer	Installation & Docker — Docker, Azure, Cloudflare, nginx

Signing in

Open your organization’s inveazy URL and sign in with the email and password from your administrator. Use Forgot password on the sign-in page if needed. After auth you may need to pick a workspace if your account belongs to more than one tenant. When enabled on Public site branding, public Sign up for a demo registers into the configured demo workspace (usually sandbox) if self-registration is on there — see Tenant workspaces.

Lab installs may include seeded demo accounts — rotate those passwords or disable them before exposing the host (see Integrations and AppHubWeb ReadMe).

Navigation — four ideas

• Hub launcher (/) — tiles for every module enabled for you. Good first stop after sign-in.
• Megamenus (top bar) — ADMIN, HUB, CRM, PM, SCM group related screens the way the app dropdowns do.
• Dashboards (/dashboard) — read-only analytics (pipeline, projects, P/L, sales, purchasing, inventory). Not where you edit documents.
• Help (/help) — this library; sidebar order matches megamenus plus Assistant and Roadmap (About, glossary, planned modules, changelog).

Hub collaboration apps (files, notifications, calendar, blog, assistant) are under HUB in the app and in the Hub and Assistant help groups.

Enabling modules

TenantAdmins turn apps on under Admin → Integrations → Applications. Disabled modules are hidden from navigation and return 404/403 if accessed directly. Roles under Roles further limit which enabled apps each user may open.

Inventory implies warehouse and order flows; Products can run lighter for catalog/storefront-only setups. Accounting adds invoices, bills, cash entries, and the financial dashboard. Pair toggles with Stripe and QuickBooks when you are ready for payments and export sync.

Common first-week paths

• Set up the workspace — Users, Integrations (SMTP, AI), My organization
• Run sales — CRM → pipeline; Sales orders when deals become fulfillment
• Run the warehouse — SCM menu overview → Buy side (products, POs, receipts, on-hand)
• Run the storefront — Storefront overview → Web orders fulfillment
• Close the books — Accounting overview, vendor bills, invoices, QB export batches
• Use AI — enable Assistant in Integrations → Assistant overview

Using this help library

Sections follow the app megamenus: Tenant Admin, Admin, Hub, CRM, PM, SCM (Buy side, Sell side, Accounting, Storefront), plus Assistant and Roadmap (About, glossary, planned modules, changelog). Use the search box in the sidebar to jump to a topic. SCM has the longest trail — start with SCM menu overview and End-to-end workflows if you are new to ERP-style document chains.

This guide is for the person installing inveazy for an organization. Everyday users do not need any of this.

What you are setting up

1. SQL Server — your own server, Azure SQL, or SQL Server in a Docker container.
2. Database — create AppHubDb and install AppHubDb.dacpac with SSMS and SqlPackage.
3. AppHubWeb — run docker-compose.web.yml with a connection string to that database.

Docker runs the website only. SQL Server can be Docker too, but the database install is still done with SSMS — not by starting the web container.

Installation order

1. Prepare the app server — Docker (and optional stack manager).
2. Run SQL Server — existing server or Docker.
3. Connect with SSMS — create the database; Local recovery SIMPLE.
4. Install the DACPAC — SSMS + SqlPackage from Command Prompt.
5. Deploy AppHubWeb — compose file + connection string.
6. Optional production settings — public URL, Stripe, QuickBooks, SMTP.

Step 1 — Prepare the app server

This machine runs the inveazy website container. It must be able to reach SQL Server on the network (port 1433).

• Docker Engine + Compose v2 — Install Docker
• Stack manager (optional) — Dockhand, Dockge, or Portainer
• Registry access — pull the apphubweb image (docker login to your registry)

docker --version
docker compose version

Step 2 — Run SQL Server

Pick one path below. Skip the Docker section if you already have SQL Server or Azure SQL.

Option A — SQL Server in Docker

Run Microsoft SQL Server 2022 in a container on your Linux server (or the same machine where AppHubWeb will run). Data is kept in a Docker volume so it survives container restarts.

Start SQL Server with Docker Compose — create a file named docker-compose.sql.yml on the server:

services:
  sqlserver:
    image: mcr.microsoft.com/mssql/server:2022-latest
    container_name: apphubdb-sql
    hostname: apphubdb-sql
    restart: unless-stopped
    ports:
      - "1433:1433"
    environment:
      ACCEPT_EULA: "Y"
      MSSQL_SA_PASSWORD: "YourStrong!Passw0rd"
      MSSQL_PID: "Developer"
    volumes:
      - apphubdb_sql_data:/var/opt/mssql

volumes:
  apphubdb_sql_data:

Replace YourStrong!Passw0rd with a strong password that meets SQL Server policy (upper, lower, number, symbol). Save that password — you need it for SSMS and SqlPackage as login sa.

From a terminal on the server, in the folder with that file:

docker compose -f docker-compose.sql.yml up -d

Wait about 30–60 seconds for SQL Server to finish starting. Check status:

docker ps
docker logs apphubdb-sql

When ready, the logs show SQL Server is accepting connections. The repo also has docker-compose.yml with the same SQL service if you prefer that file.

Connect from SSMS (Windows PC):

• Server name: YOUR_SERVER_IP,1433 — the LAN IP of the Docker host (e.g. 10.0.0.128,1433). If SSMS runs on the same machine as Docker, try localhost,1433.
• Authentication: SQL Server Authentication
• Login: sa
• Password: the MSSQL_SA_PASSWORD you set above
• On the login dialog, open Options >> → check Trust server certificate (common for Docker / lab SQL).

If connection fails: confirm port 1433 is open on the server firewall and that docker ps shows the container running.

Option B — Existing SQL Server or Azure SQL

Use SQL you already manage — a Windows SQL instance, a VM, or Azure SQL Database. Connect with SSMS the way you normally do (server admin login). Ensure the app server can reach the instance on port 1433 and that firewall rules allow the AppHubWeb host.

Step 3 — Connect with SSMS and create the database

On a Windows PC, open SSMS and connect as SQL administrator (sa for Docker SQL, or your usual admin login).

1. Connect Object Explorer to your server (see Option A for Docker connection details).
2. Open a New Query window connected to master.
3. Run:

CREATE DATABASE AppHubDb;

On Azure SQL, create AppHubDb in the Azure portal instead if you prefer. Refresh Object Explorer and confirm AppHubDb appears under Databases.

Local / Docker SQL — recovery model (important)

New databases on SQL Server (including Docker) often inherit FULL recovery from the model database. Without regular transaction log backups, the log file can grow to many gigabytes over weeks of publishes and testing — while the data file stays small.

For Local LAN / Docker / self-hosted lab installs where you do not need point-in-time restore from log backups, set SIMPLE recovery right after create (and on any existing local DB that has already ballooned):

ALTER DATABASE AppHubDb SET RECOVERY SIMPLE;
-- Optional reclaim after switching (local only):
-- USE AppHubDb;
-- DBCC SHRINKFILE (N'AppHubDb_log', 128);

Replace AppHubDb with your database name if different (provisioned customer DBs often use the workspace slug). Local customer provision scripts apply RECOVERY SIMPLE automatically for new databases.

Azure SQL: leave FULL recovery. Azure manages log truncation with automated backups — do not switch Azure databases to SIMPLE for this reason.

Step 4 — Install AppHubDb.dacpac (SSMS + SqlPackage)

The DACPAC creates all tables, security, and seed data, plus the contained user AppHubUser. AppHubWeb does not do this step for you.

The DACPAC needs a password variable (AppHubUserPassword). Run SqlPackage from Command Prompt on the SSMS PC (SqlPackage installs with SSMS). The SSMS Deploy Data-tier Application wizard cannot set that variable.

You need:

• AppHubDb.dacpac — from your maintainer, or build AppHubDb/AppHubDb.sqlproj in Visual Studio (Release), or download the AppHubDb-build pipeline artifact
• A password you choose for AppHubUser — save it; the AppHubWeb connection string uses the same password

Run SqlPackage from Command Prompt:

1. Open Command Prompt on the Windows machine where SSMS is installed.
2. Find SqlPackage.exe — common paths:
   • C:\Program Files\Microsoft SQL Server\160\DAC\bin\SqlPackage.exe
   • C:\Program Files\Microsoft SQL Server\150\DAC\bin\SqlPackage.exe
   Or download from Microsoft SqlPackage.
3. Run (edit paths and passwords for your server):

"C:\Program Files\Microsoft SQL Server\160\DAC\bin\SqlPackage.exe" ^
  /Action:Publish ^
  /SourceFile:"C:\path\to\AppHubDb.dacpac" ^
  /TargetConnectionString:"Server=YOUR_SERVER_IP,1433;Initial Catalog=AppHubDb;User ID=sa;Password=YOUR_SA_PASSWORD;Encrypt=True;TrustServerCertificate=True" ^
  /Variables:AppHubUserPassword="YOUR_APPHUB_USER_PASSWORD" ^
  /p:RegisterDataTierApplication=false

For Docker SQL, use sa and your container MSSQL_SA_PASSWORD. For Azure SQL, use your server admin login and TrustServerCertificate=False.

Wait for Successfully published database. If publish fails, close other SSMS query tabs that have AppHubDb open and try again.

Confirm in SSMS:

1. Expand AppHubDb → Tables — you should see many tables.
2. File → Connect Object Explorer (second connection).
3. Login: AppHubUser. Password: your AppHubUserPassword.
4. Options >> → Connect to database = AppHubDb (not master).
5. Click Connect. If this works, AppHubWeb will connect too.

Alternative: Visual Studio — open AppHubDb.sqlproj, Publish, set SqlCmd AppHubUserPassword in the publish dialog.

More detail: AppHubDb/ReadMe.md

Step 5 — Deploy AppHubWeb (compose file + connection string)

Paste docker-compose.web.yml into your stack manager and set:

• APPHUBWEB_IMAGE — e.g. myregistry.azurecr.io/apphubweb:latest
• ConnectionStrings__DefaultConnection — points at AppHubDb on your SQL Server

Dockhand / Dockge / Portainer: new stack → paste YAML below → add variables → deploy.

Terminal:

docker compose -f docker-compose.web.yml up -d

docker-compose.web.yml

Use the file from the repo root (preferred). Essential shape:

services:
  apphubweb:
    image: ${APPHUBWEB_IMAGE}
    pull_policy: always
    container_name: apphubweb
    restart: unless-stopped
    ports:
      - "${WEB_PORT_SPEC:-18548:5148}"
    extra_hosts:
      - "host.docker.internal:host-gateway"
    environment:
      ASPNETCORE_URLS: http://+:5148
      ASPNETCORE_ENVIRONMENT: "${ASPNETCORE_ENVIRONMENT:-Production}"
      Web__TrustForwardedHeaders: "${Web__TrustForwardedHeaders:-true}"
      Web__ShowDevHub: "${Web__ShowDevHub:-true}"
      Web__EnableOpenApiDocs: "${Web__EnableOpenApiDocs:-true}"
      DataProtection__KeysPath: "${DataProtection__KeysPath:-/app/dpkeys}"
      ConnectionStrings__DefaultConnection: "${ConnectionStrings__DefaultConnection}"
      # Ops-only local provision (default off). Leave false on customer stacks.
      Provision__Enabled: "${Provision__Enabled:-false}"
      Provision__ListenerUrl: "${Provision__ListenerUrl:-}"
      Provision__SharedSecret: "${Provision__SharedSecret:-}"
      Provision__DefaultHostPort: "${Provision__DefaultHostPort:-10150}"
    volumes:
      - apphubweb_dataprotection_keys:/app/dpkeys

volumes:
  apphubweb_dataprotection_keys:

Provision install (ops only): Admin → Provision is available only on inveazy.com, hvt.inveazy.com, and hivoltech.com when Provision__Enabled=true and the host listener is running (deploy/docker-compose.provision-listener.yml). Customer slug stacks and localhost do not show the page (404). Do not copy Provision secrets into customer Dockhand env. Details: repo deploy/PROVISION-LOCAL.md.

Connection string — SQL Server in Docker on the same host as AppHubWeb:

ConnectionStrings__DefaultConnection=Server=10.0.0.128,1433;Database=AppHubDb;User Id=AppHubUser;Password=YOUR_APPHUB_USER_PASSWORD;Encrypt=True;TrustServerCertificate=True;MultipleActiveResultSets=true

Use the server’s LAN IP (not localhost) — from inside the AppHubWeb container, localhost means the container itself, not the SQL container. Replace 10.0.0.128 with your host’s IP.

Connection string — Azure SQL:

ConnectionStrings__DefaultConnection=Server=tcp:yourserver.database.windows.net,1433;Database=AppHubDb;User Id=AppHubUser;Password=YOUR_APPHUB_USER_PASSWORD;Encrypt=True;TrustServerCertificate=False;MultipleActiveResultSets=true

Test: http://127.0.0.1:18548 on the app server. Do not delete apphubweb_dataprotection_keys on redeploy.

Step 6 — Dockhand environment block (production)

Step 5 only needs APPHUBWEB_IMAGE and ConnectionStrings__DefaultConnection to get running. When you go live, paste the block below into your stack manager’s Environment panel (Dockhand, Dockge, or Portainer). Use the same variable names — no .env file is required on the server.

Replace every CHANGE_ME and example URL with real values for this customer. Never commit this block with live secrets to Git.

If SQL Server runs in Docker on the same host, set TrustServerCertificate=True in the connection string (as in Step 5). Azure SQL uses TrustServerCertificate=False.

# Required — replace yoursite.com / YOUR_SLUG with this install's values
APPHUBWEB_IMAGE=myregistry.azurecr.io/apphubweb:latest
ASPNETCORE_ENVIRONMENT=Production
ConnectionStrings__DefaultConnection=Server=YOUR_SQL;Database=YOUR_SLUG;User Id=AppHubUser;Password=CHANGE_ME;Encrypt=True;TrustServerCertificate=False;MultipleActiveResultSets=true

# Site URL + proxy (customer public hostname)
Web__PublicBaseUrl=https://yoursite.com
Web__TrustForwardedHeaders=true
Web__ShowDevHub=false
Web__EnableOpenApiDocs=false
Web__DisableSandboxSeededDemoLogins=true
DataProtection__KeysPath=/app/dpkeys

# Host email (optional if the workspace uses custom SMTP in Admin → Integrations)
Smtp__Host=smtp.mailersend.com
Smtp__Port=587
Smtp__Ssl=true
Smtp__User=CHANGE_ME
Smtp__Password=CHANGE_ME
Smtp__From=noreply@yoursite.com
Smtp__FromName=YOUR_COMPANY

# Stripe commerce — omit this whole block from Dockhand for customer installs.
# Enter secret, publishable, and webhook signing secrets in the app:
#   Admin → Integrations → Providers → Payments
# (Do NOT paste platform / inveazy subscription keys.) Uncomment stack Stripe__* only if you
# intentionally drive checkout from compose env instead of Integrations.
# Stripe__SecretKey=
# Stripe__PublishableKey=
# Stripe__WebhookSecret=
# Stripe__InvoiceCheckoutSuccessUrl=/pay/invoice?success=1&session_id={CHECKOUT_SESSION_ID}
# Storefront catalog workspace (config, not Integrations) — Core_Tenant.Slug for /store:
# Web__Store__CommerceTenantSlug=tenantname   # this install's workspace slug; not sandbox

# QuickBooks — Intuit OAuth app for this install (tenant Connects company in Admin → Integrations)
QuickBooks__ClientId=CHANGE_ME
QuickBooks__ClientSecret=CHANGE_ME
QuickBooks__Environment=production
QuickBooks__RedirectUri=https://yoursite.com/api/integrations/quickbooks/callback
QuickBooks__WebhookVerifierToken=CHANGE_ME

# Optional
ConnectionStrings__AzureStorage=DefaultEndpointsProtocol=https;AccountName=CHANGE_ME;AccountKey=CHANGE_ME;EndpointSuffix=core.windows.net
Mapbox__AccessToken=pk.CHANGE_ME

# Provision__* — omit on customer installs (defaults stay false). Ops hosts only: see note under docker-compose.web.yml.

Commerce Stripe on a dedicated install belongs to that customer — enter it under Admin → Integrations → Providers → Payments (and omit the Stripe__* block from Dockhand). Do not copy Hivoltech / inveazy platform keys. Copy the webhook URL from that Payments tab into the Stripe Dashboard. See Stripe payments. QuickBooks ClientId/Secret stay in env; the tenant still Connects their QBO company under Integrations → Providers → Accounting.

What each section does is documented in Prod.md at the repo root. Variable names only (no secrets): .env.web.example.

Check that it works

1. AppHubWeb logs show no SQL errors.
2. http://127.0.0.1:18548 loads.
3. Sign-in works (change demo passwords before go-live).
4. Add users under Admin → Users.

Common problems

• SSMS cannot connect to Docker SQL — check docker ps, firewall on port 1433, use YOUR_SERVER_IP,1433, enable Trust server certificate.
• AppHubWeb cannot connect but SSMS can — connection string must use the host LAN IP, not localhost, when SQL and web are both in Docker on the same machine.
• Login failed for AppHubUser — include Database=AppHubDb; password must match AppHubUserPassword from SqlPackage.
• DACPAC not installed — publish AppHubDb.dacpac before starting AppHubWeb.
• Image pull fails — docker login; APPHUBWEB_IMAGE must not include https://.

See also production.md, Prod.md, and AppHubDb/ReadMe.md.

Tenant Admin is the platform-owner lane in inveazy. Users with the TenantAdmin role can provision workspaces, connect external services, set operational letterhead, and control the public marketing site. If you only manage users and roles inside one workspace — without provisioning new tenants — you may be an Admin instead; see Admin menu overview.

These screens still live under the top-bar ADMIN megamenu, but the help library groups them here so Tenant Admins can find platform tasks without wading through dashboard analytics. The ADMIN dropdown’s Platform & support column maps to this section; the middle ADMIN column (users, roles) and Dashboards column are documented under Admin in the sidebar.

Topics in this group

• Tenant workspaces — catalog of workspaces you administer
• Self-registration — per-workspace toggle on workspace detail (Demo, pilots, etc.)
• New tenant workspace — provision another isolated tenant
• Multitenancy — isolation, TenantId scoping, and terminology
• My organization — letterhead on POs, invoices, and operational PDFs
• Integrations — applications, Stripe, QuickBooks, SMTP, AI, read-only SQL
• Public site branding — anonymous marketing home and blog frame

Typical onboarding order

1. Understand Multitenancy and open Tenant workspaces.
2. Provision customer workspaces via New tenant workspace (or the first-run setup wizard on a fresh install).
3. Switch into the workspace and enable modules under Integrations → Applications.
4. Set My organization letterhead before issuing SCM documents.
5. Connect Stripe, QuickBooks, and SMTP on the same Integrations page.
6. Configure Public site branding if you use the marketing landing page.
7. Invite users via User manager (documented under Admin).

TenantAdmin and Admin both see the ADMIN menu; individual links are hidden when your role lacks permission.

Admin → ADMIN → Tenant workspaces (/admin/tenants) lists every workspace (tenant) you administer on this inveazy install. This screen is for TenantAdmin only. It is one of the most important concepts to understand: a workspace is not a CRM account or customer company — it is the isolated container that holds all of your team's CRM accounts, products, users, and settings.

One physical inveazy deployment can host many workspaces. A software vendor might run one install for fifty customers, each with their own workspace slug and data. A single company might use one workspace for production and another for training. Each workspace has its own module toggles, roles, integrations, and document number sequences. Data never mixes between workspaces unless a platform operator explicitly copies it outside the app.

From the catalog you can open a workspace detail page to see its slug, enabled modules, user list, and self-registration settings. Use the workspace switcher in the top bar to change which workspace you are signed into; the tenant catalog is the map of workspaces you control.

Demo / SandBox and customer workspaces

Fresh installs seed only SandBox (sandbox) for training sample data. The lean Demo workspace (demo) used for public Sign up for a demo is created manually on the marketing demo host — it is not seeded by the dacpac and must never be removed by a republish. That CTA (when enabled under Public site branding) targets Web:PublicSite:DemoTenantSlug (default demo) with self-registration on; keep SandBox self-reg off. Paid customer databases should not include a demo tenant.

To offer public signup on the marketing host: keep that demo workspace, enable self-registration on its detail page, and leave Show Sign up for a demo button checked. To hide the button on a paid customer site, uncheck that option even if SandBox still exists for training.

Customer workspaces are created via New tenant workspace or the first-time setup wizard. Production data should live in a dedicated workspace with real users and integrations — not in SandBox.

Self-registration (per workspace)

On a workspace detail page, TenantAdmins can enable self-registration for that slug only. When on, the page shows a Request access link you can copy to prospects or staff. Registrants submit name and email; you approve or deny in the registration queue before they can sign in.

Any workspace can use self-registration — not only SandBox. Turn it on only for workspaces you trust on a shared host (SandBox for public trials; a private pilot slug for a known customer). Marketing Sign up for a demo targets the configured demo slug; the link only works while self-registration is enabled on that workspace and the public-site button toggle is on.

Tenant workspaces vs User manager

Tenant workspaces shows the list of workspaces and, on detail, users for that chosen workspace. User manager always shows users in the workspace you are currently signed into. If you administer multiple workspaces, switch context in the header before opening User manager, or open users from the specific workspace detail page.

See also Multitenancy for isolation, security, and database scoping in more depth.

Admin → ADMIN → New tenant workspace (/admin/tenants/add) provisions another isolated workspace on the same install. Only TenantAdmin users see this link. Use it when onboarding a new customer, spinning up a training environment, or separating subsidiaries that must not share data.

Creating a workspace typically involves choosing a slug (short URL-safe identifier used in workspace switcher and sometimes URLs), a display name, and initial settings. The new workspace starts with default roles, empty operational data, and module defaults — you then enable applications, invite users, and configure integrations the same way you would for your first workspace.

Provisioning is intentionally separate from CRM Accounts. A CRM account is a customer your business sells to inside a workspace. A tenant workspace is the business environment itself. Confusing the two is a common onboarding mistake: "Add account" in CRM does not create a new workspace.

After you create a workspace

1. Switch into the new workspace with the header workspace switcher.
2. Open Integrations → Applications and enable the modules this customer purchased.
3. Invite users via User manager or enable self-registration on the workspace detail page.
4. Complete My organization letterhead for POs and invoices.
5. Connect QuickBooks, Stripe, and SMTP as needed.

Admin → Platform & support → My organization (/admin/my-organization) stores your company's legal letterhead — the name, logo, address, phone, tax ID, and related fields printed on operational documents. This is TenantAdmin configuration for the workspace you are in.

Letterhead is not the same as Public site branding. Letterhead appears on PDFs and printouts your business sends in the course of operations: purchase orders to vendors, sales order confirmations, invoices, packing slips, and similar SCM paperwork. Public site branding controls what anonymous visitors see on the marketing home page and blog. Many companies use the same logo in both places, but the data is stored separately so marketing can change a hero image without breaking PO layouts.

When you fulfill orders or email invoices, the system pulls organization fields into templates. Incomplete letterhead produces incomplete documents — set this up before go-live even if the public marketing site is not finished.

What to configure

• Legal name — as it should appear on contracts and tax documents.
• Logo — displayed on document headers; use a high-contrast image readable when printed.
• Address and phone — remit-to and contact blocks for vendors and customers.
• Tax identifiers — where applicable for invoices and compliance.

The page includes a letterhead preview so you can see approximate layout before printing a real PO. Changes apply to new documents; already-issued PDFs are not retroactively regenerated.

Admin → Platform & support → Integrations (/admin/integrations) is where the workspace meets the outside world: which apps are turned on, payment and accounting providers, outbound email, AI, analytics database access, and sync health. Only TenantAdmin should routinely change these settings. API keys and secrets are stored encrypted; after save they are not shown again — keep a secure record when rotating keys.

Applications tab

Choose which hub modules appear in the sidenav and HUB megamenu. Disabling an application hides navigation entry points and causes direct URLs to return 404 for users who are not administrators. Admin itself and public site settings remain available regardless. Enabling Inventory typically implies warehouse and order flows; Products alone is a lighter catalog tier for storefront SKUs without full SCM.

Providers tab

Connect external services by category:

• Accounting — QuickBooks Online OAuth (connect the company / realm). Products, vendors, customers, invoices, vendor bills, and payments can sync; use Sync status afterward.
• Payments — Stripe commerce for invoices and storefront. Enter secret, publishable, and webhook signing secrets; copy the webhook URL into Stripe Dashboard → Webhooks. Checkout still uses stack Stripe__* until runtime BYOK override ships — keep Dockhand/compose env in sync. Details: Stripe payments.
• Shipping & maps / AI — carrier and map tokens; assistant BYOK keys (enable the assistant on the AI tab).

Each dedicated install uses that customer’s own Stripe and QuickBooks accounts — not Hivoltech platform SaaS keys.

Sync status tab

When QuickBooks is connected, Sync status summarizes Site_ExternalSync rows: counts synced, pending, and errored by record type (Product, Vendor, Customer, Invoice, VendorBill, Journal, and others). Recent errors list with one-click Re-sync. A red badge on the tab highlights outstanding failures. Use this page after posting journals or issuing invoices to confirm QBO received them.

Email (SMTP) tab

Override system email with tenant-specific SMTP — host, port, TLS, credentials, from/reply addresses. When custom SMTP is off, the host uses application-wide Smtp settings from server configuration. Tenant SMTP is used for notifications, invoice emails, and other outbound mail initiated inside the workspace.

AI assistant tab

Configure the workspace assistant: built-in model endpoint or bring your own key (BYOK), optional read-only SQL access for MODULE SCOPED DATA, and toggles for which modules the assistant may query. Without read-only data enabled, the assistant answers from general knowledge and your prompt only — not live inventory or pipeline numbers.

Read-only database tab

Provision a per-tenant SQL login for Power BI, Excel, Tableau, or SSMS reporting. Row-level security limits results to the workspace TenantId. This is reporting access, not a backup or migration path — operational changes still happen inside the app.

Operational letterhead is under My organization; marketing site appearance is under Public site branding.

Admin → Platform & support → Public site branding (/admin/organization-site) controls the anonymous marketing experience — what people see at your organization's public URL before they sign in. TenantAdmin only. This is separate from signed-in hub chrome and separate from operational letterhead on POs/invoices.

General — landing page and blog toggles

Use landing page decides whether / for anonymous visitors shows a marketing home or redirects toward sign-in. Use blog controls whether public blog routes are active. Signed-in users always get the hub launcher at / regardless of the landing toggle — the toggle affects guests only.

Show Sign up for a demo button controls whether guests see that CTA on the public home page. Turn it off for paid customer sites that should not offer public trials. When it is on, visitors register into the demo workspace from host config (Web:PublicSite:DemoTenantSlug, usually demo on the marketing host). Create or keep that tenant under Tenant workspaces and enable self-registration on it, or the button will open a page that says signup is unavailable.

Show integrations strip on landing page controls the Connects to enterprise data, payments, and services logo band (and related deployment badges). Uncheck it when that marketing strip is not appropriate for the customer site.

Show Pricing button and page controls the header Pricing link, home-page Features & pricing CTAs, and the public /pricing page (inveazy SaaS plans). Leave it on for the marketing/demo host; uncheck it on paid customer installs.

Company display name is the public header/footer brand and the signed-in topbar label. Sidebar name is the left sidenav brand only — leave it blank to reuse the company display name, or set a shorter label when the full company name is too long for the menu.

Home hero and theme

Choose theme skin, color mode, navbar style, and hero imagery for the stock inveazy landing layout. Upload a hero image (JPEG, PNG, WebP, GIF, or SVG) or restore the default illustration (/images/center.jpg). The Home hero tab includes a Quill editor for the subhead (bold, lists, links, text size) — same idea as footer About. Use Preview home after saving to verify appearance on desktop and mobile.

Where branding is stored

Uploaded hero, logo, favicon, and PWA assets are saved in the database (Site_OrganizationSiteProfile for URLs and copy; Site_PublicSiteAsset for image bytes). The app also writes a cache copy under wwwroot/images/public-site/ and wwwroot/images/pwa/site/ on the server — those files are not in Git. When localhost and production share the same database, a branding change from either environment applies to both; each app server rebuilds its local cache from SQL on startup or first request.

Custom landing page

When Use custom landing page is enabled, replace the stock layout with your own HTML blocks — mission statements, product highlights, calls to action — while still using shared theme controls for colors and header/footer chrome.

Contact, footer, and social

Configure inquiry email routing, footer text, social network links, and rich "about" content shown on the public site. These fields feed the marketing footer, not SCM documents.

Brand & PWA

Public logo, favicon-related assets, theme color, and progressive-web-app metadata for add-to-home-screen experiences on mobile devices.

Blog authoring for employees still happens under Hub → Blog; this screen only controls whether published posts are visible publicly and how the public site frame looks around them.

Multitenancy is how one inveazy installation serves many separate organizations without mixing their data. If you are new to SaaS or hosted business software, think of each tenant (workspace) as its own company environment: own users, own products, own invoices — sitting on shared application code and database server infrastructure.

Every operational row in the database carries a TenantId (or equivalent scope) so queries always filter to the workspace you signed into. Users can belong to more than one workspace, but they work in one at a time via the workspace switcher in the header. Switching workspace changes every list, document, and dashboard you see.

Tenant vs workspace vs CRM account

Tenant and workspace mean the same thing in the UI. A CRM account is a customer company you sell to inside a workspace — not another tenant. A CRM organization is often a legal entity in your directory (vendor, partner, or customer). Do not confuse provisioning a new tenant with adding a CRM account.

Isolation and reporting

Application RBAC limits which modules a user sees within a tenant. Optional read-only database logins (Admin → Integrations) add SQL Server row-level security so BI tools cannot read another tenant's rows even if someone misconfigures a connection. See Tenant workspaces for provisioning and Integrations for external connections per tenant.

The ADMIN button in the top navigation bar is your control center for the whole inveazy installation and for the workspace you are signed into. It is aimed at people who configure the system — typically a TenantAdmin or Admin role — not at day-to-day warehouse or sales staff. If you do not see the ADMIN menu, your role does not include those permissions; ask your workspace administrator.

Unlike module menus (CRM, PM, SCM), the Admin menu is organized around how you run the workspace, not around a single business process. The ADMIN dropdown has three columns that match the app:

• Dashboards — read-only analytics: overview launcher (/dashboard), CRM, project, financial, and SCM dashboards (sales, purchasing, inventory) when those modules are enabled. Documented in this Admin help group.
• ADMIN — users and security for the workspace you are signed into: User manager and Roles. Also documented here.
• Platform & support — workspace provisioning, letterhead, integrations, and public marketing site. Those items are TenantAdmin tasks — see the Tenant Admin help group above.

Think of Admin as the layer above CRM, PM, and SCM for day-to-day workspace operations. Tenant Admin is the narrower platform-owner lane for provisioning tenants and wiring external services. Many small businesses have one person in both roles; larger deployments split them.

Who should use which Admin item?

A small business might have one TenantAdmin who does everything. A larger deployment often splits responsibilities:

• IT / platform owner — Tenant Admin topics: tenant workspaces, integrations, read-only database, SMTP, AI keys.
• HR or office manager — User manager, Roles, and My organization letterhead (TenantAdmin configures letterhead; Admin may request updates).
• Marketing — Public site branding (TenantAdmin).
• Executives — dashboards only, no configuration.

Work through dashboards in this group to orient yourself, then users and roles before inviting the team. Tenant provisioning and integrations live under Tenant Admin overview.

Documentation for Hub, CRM, PM, and SCM megamenus is in the sidebar groups below — each menu link has its own page.

Admin → Dashboards → Home opens the main app landing page at / when you are signed in. This is not the public marketing website visitors see before they log in; it is the hub launcher — a grid of tiles for every module your workspace has enabled (CRM, PM, Blog, Inventory, and so on).

After sign-in, most users start here to choose what to work on. The home page answers the question: What can I open in this workspace? Only modules turned on under Admin → Integrations → Applications appear as tiles. If Inventory is enabled, you will see SCM-related entry points; if only Products is enabled, you may see a lighter catalog-focused tile set.

The home launcher is intentionally simple. It does not show KPIs or alerts — those live on the Dashboard item in the same Admin column. Use Home when you want to jump into a module; use Dashboard when you want a quick health read across modules you have access to.

Relationship to the public site

Anonymous visitors hitting your organization's URL may see a marketing landing page instead of the sign-in screen, depending on Public site branding → Use landing page. Once authenticated, / is always the signed-in hub home, not the marketing layout. Keeping that distinction clear prevents confusion between brand/marketing settings and signed-in navigation.

Admin → Dashboards → Dashboard (/dashboard) is the dashboard launcher — a grid of cards that link to each analytics screen your role can access. Where the hub home (/) opens modules, this page answers: How is the business performing?

Cards appear based on enabled applications and permissions. Everyone with CRM may see the CRM dashboard card; Accounting unlocks the financial dashboard; Inventory unlocks purchasing, sales, and inventory dashboards. Open a card to drill into charts, KPIs, filters, exports, and optional Analyze buttons that send context to the Workspace assistant.

The same dashboards are listed under the Dashboards submenu in the left sidenav (and in the horizontal nav on smaller layouts). The ADMIN megamenu shows Home, Dashboard, CRM, and Project links in its first column; finance and SCM dashboards are on the launcher and sidenav even when they are not duplicated in that megamenu column.

All dashboard screens

Screen	Route	Requires
CRM dashboard	/dashboard/crm	CRM
Project dashboard	/dashboard/projects	PM
Financial dashboard	/dashboard/finance	Accounting
Sales dashboard	/dashboard/scm-sales	Inventory
Purchasing dashboard	/dashboard/scm-purchasing	Inventory
Inventory dashboard	/dashboard/scm-inventory	Inventory

When to use a module dashboard instead

If your question is specifically about sales pipeline health, open CRM dashboard. If it is about sprint load and project risk, open Project dashboard. For GL profit & loss and cash, use Financial dashboard. For open POs, booked sales, or stock on hand, use the three SCM dashboards. Operational SCM dashboards show document-level KPIs; the financial dashboard shows posted journal balances — both are useful and answer different questions.

Admin → Dashboards → CRM dashboard (/dashboard/crm) focuses on customer relationship metrics: pipeline value, stage distribution, activity trends, and related KPIs. This link appears only when the CRM module is enabled for the workspace.

CRM (Customer Relationship Management) is the part of the app where you track who you sell to and where deals stand before they become operational orders. Organizations and accounts represent companies; contacts are people; leads are early-stage prospects; opportunities are active deals with amounts and expected close dates. The CRM dashboard aggregates those records into charts and totals so managers can see funnel health without opening every opportunity.

The dashboard is read-only analytics. To change data — move a deal to another stage, log a call, convert a lead — use the CRM megamenu (Organizations, Pipeline, Opportunities, Activities). The dashboard tells you what shape the pipeline is in; the CRM menus are where work happens.

Typical workflow

A sales lead might check the CRM dashboard each morning for stalled opportunities and week-over-week trend arrows, then open CRM → Pipeline to drag cards across stages. Activities due today often surface through CRM list views or notifications rather than only through the dashboard.

Admin → Dashboards → Project dashboard (/dashboard/projects) summarizes project portfolio health: open work items, sprint progress, workload by assignee, and related KPIs. It appears when the Project Management (PM) module is enabled.

Project management in inveazy is for delivering work — internal initiatives, client projects, product development, or service engagements. A project groups work items (tasks, bugs, stories). Sprints time-box work; the Kanban board visualizes status columns; the Gantt chart shows schedules. The project dashboard rolls those details up for leads who need a portfolio view across many projects.

Like the CRM dashboard, this page is for monitoring. Updating assignments, moving cards on the board, or editing sprint dates happens under the PM megamenu (Projects hub, Tasks board, Sprints, Gantt).

CRM vs PM dashboards

CRM dashboards track revenue opportunities with customers. PM dashboards track execution of work your team agreed to deliver. A professional services firm might use both: CRM for signing the deal, PM for delivering the project. For a card-style portfolio snapshot without charts, PM → Overview (/pm/overview) is an alternative entry point.

Financial dashboard (/dashboard/finance) is the general ledger (GL) lens — profit & loss, cash flow, and account balances from posted journals. It unifies SCM-driven activity (invoices, bills, inventory movements) with manual Income & expenses cash entries. Open it from /dashboard, the sidenav Dashboards submenu, or the Accounting area when enabled.

This is read-only analytics. Posting and approving documents happens in SCM screens (sales orders, vendor bills, etc.) and cash-entry forms. QuickBooks sync is separate — see QuickBooks setup and Accounting overview for how local GL relates to exports.

Filters and period

Slice by organization, customer (account), project, and reporting period (year to date, last 12 months, this month, all time, or custom dates). KPI cards and charts refresh when you change filters. Use Export for PDF, Excel, or CSV snapshots of the current view.

Analyze with AI

The Analyze P&L button opens the Workspace assistant with financial context so you can ask for narrative summaries — still verify numbers against the on-screen KPIs before sharing externally.

SCM dashboards vs financial dashboard

SCM sales, purchasing, and inventory dashboards show operational documents (orders, POs, on-hand SKUs). Recognised revenue, AP expense, and inventory value on the books live here on the financial dashboard. Use both: SCM dashboards for fulfillment and spend velocity; financial dashboard for P&L and cash position.

Sales dashboard (/dashboard/scm-sales) is the operational sales view — booked order value, open backlog, fulfillment status, top customers and products, and regional breakdown when Mapbox is configured. Filter by customer, channel (desk sales vs storefront), and period. Requires the Inventory module (SCM sales documents).

Recognised revenue and accounts receivable on the GL appear on the Financial dashboard. This screen answers: What did we book? What is still open to ship? Who bought the most? Drill into Sales orders, Web orders, or Returns (RMA) to change data.

Typical KPIs

• Booked sales and order count for the selected period
• Open backlog value and lines awaiting fulfillment
• Order status mix (draft, confirmed, picking, shipped, etc.)
• Top customers and products; optional regional map
• Throughput — fill rate, pick-to-ship time, and order cycle time for the selected period

Export PDF/Excel/CSV or use Analyze to send the current filter context to the assistant. Pair with Purchasing dashboard when diagnosing supply constraints on hot sellers, and Inventory dashboard for pick-to-ship vs receiving pace.

Purchasing dashboard (/dashboard/scm-purchasing) tracks buy-side operations — vendor spend in the period, open purchase order commitment, open accounts payable, and spend by vendor. Filter by vendor and date range. Requires Inventory.

Vendor spend counts approved vendor bills in the period (not drafts or voids). Open PO value and open AP are point-in-time snapshots as of today, independent of the period filter. GL expense recognition is on the Financial dashboard; this page is for buyers and ops leads watching PO and bill pipeline.

Typical workflow

A purchasing manager reviews open PO and AP KPIs here, exports a vendor spend chart for a meeting, then opens Purchase orders or Vendor bills to approve or match receipts. Overdue PO lines that block sales often show up in both this dashboard and Backorders.

Inventory dashboard (/dashboard/scm-inventory) answers Is stock moving through the warehouse? — on-hand value and units, SKUs below reorder, expiring lots, slow/dead stock, cycle-count variance, recent movements, and low-stock alerts. Filter by warehouse and category. Requires Inventory.

Inventory value on the GL is on the Financial dashboard; this screen is operational. On-hand, expiry, and low-stock KPIs are point-in-time (as of today). Slow movers are stocked SKUs with no sale in a configurable window (default 180+ days) — consumables are excluded so gloves and supplies do not clutter the list. Cycle-count variance uses the current calendar quarter (QTR), not a rolling twelve months. A throughput section shows fill rate, pick-to-ship, and related warehouse velocity KPIs alongside the sales dashboard.

Where to act

• On-hand inventory — bin-level quantities
• Reorder alerts — SKUs below minimum, draft PO per vendor
• Cycle counts — post variances
• Backorders — demand waiting on stock
• Transfers — move stock between warehouses
• Mobile scanner — receive, pick, putaway, count on the floor

Use Analyze for assistant summaries; use Refresh after large receiving or adjustment sessions to update KPIs.

Admin → ADMIN → User manager (/admin/users) is the directory of people in the workspace you are signed into now. TenantAdmin and Admin roles can access it. From here you invite colleagues, assign roles, reset access, and open a user detail page for per-user settings.

Every person who signs in needs a user record tied to one or more workspaces. Roles (see Roles) decide which megamenus and modules appear. A warehouse clerk might have Inventory but not Admin; an AR clerk might have Accounting slices; a owner might be TenantAdmin with full configuration rights.

Adding users

Administrators can create users directly from User manager. Alternatively, self-registration lets people request access from a per-workspace link on Tenant workspaces → [workspace] → detail (Tenant workspaces). TenantAdmins enable the toggle, copy the Request access URL, and approve or deny pending requests before the person can sign in. Each workspace controls its own setting — useful for a public Demo trial (demo) or a private pilot slug. Direct invite from User manager is still faster for a handful of known emails.

Workspace context matters

User manager is always scoped to your current workspace. If you operate multiple tenants, switch workspace in the header before managing users, or manage them from Tenant workspaces → [workspace] → Users. The on-screen "How access works" callout on admin pages repeats this guidance for new TenantAdmins.

Users vs CRM contacts

Users can log in and have roles. CRM contacts are people you track for sales and support — they may never sign in. A customer's buyer might exist only as a CRM contact; your employee exists as a user. Linking the two is optional and separate from authentication.

Admin → ADMIN → Roles (/admin/roles) defines role-based access control (RBAC) for the current workspace. A role is a named bundle of permissions — which hub applications a user may open, and (for built-in admin roles) whether they can configure the workspace.

Built-in roles include TenantAdmin (full workspace configuration), Admin (user and role management without some tenant-provisioning actions), User (standard module access), and BlogEditor (content publishing). Built-in roles cannot be deleted; on most workspaces you can edit which applications they include. Custom roles can be added for job titles like "Warehouse", "AR Clerk", or "Sales Rep".

Applications vs roles

Integrations → Applications turns modules on for the whole workspace (CRM on/off, Inventory on/off). Roles decide which enabled modules a given user sees. If Inventory is enabled workspace-wide but a user's role excludes it, that user will not see SCM in the megamenu — even though the data exists for other roles.

This two-layer model lets you sell SCM to a company but restrict accounting exports to finance staff. Future work may split Accounting and Inventory into finer module codes; roles will follow the same pattern.

Practical guidance

• Give few people TenantAdmin; use Admin for day-to-day user management.
• Create custom roles that mirror real job functions instead of one "User" role for everyone.
• After changing role applications, ask affected users to refresh or sign out — megamenu visibility updates on next load.
• Disabled modules return 404 if someone bookmarks a URL — roles and application toggles both matter.

The HUB megamenu groups applications that support everyday collaboration — files, notifications, calendar, AI assistant, and blog — rather than a single business line like CRM or SCM. Open it from the top bar after sign-in. What you see depends on which hub modules are enabled under Admin → Integrations → Applications.

The dropdown has three columns:

• Hub apps — Hub overview (workspace landing), File Manager, Notifications (inbox and compose), Calendar.
• Assistant & Blog — Workspace assistant (AI chat) and Blog hub / All posts. About inveazy also appears here in the app menu; in Help it lives under Roadmap.
• Next sessions — roadmap placeholders (not documented as product features).

Open the sidebar Hub group for hub apps. AI documentation is in the Assistant group — start with Assistant overview.

The CRM megamenu is where you manage customers and sales pipeline before work becomes purchase orders or projects. CRM answers: Who are we selling to? What deals are open? What did we last discuss? It does not move physical inventory — that is SCM.

Columns in the CRM dropdown:

• ORG — Organizations (legal entities in your directory), Accounts (sell-to customers), Contacts (people), Leads (prospects).
• Pipeline — Pipeline board, Opportunities table, Activity board, Activities list.
• Dashboard & navigation — CRM dashboard, Deals overview, CRM Home hub page.

Open the sidebar CRM group for documentation on each screen — organizations, accounts, pipeline, opportunities, activities, and more.

The PM (Project Management) megamenu plans and tracks work delivery — internal projects, client engagements, or product development. It answers: What tasks are open? Who owns them? Are we on schedule?

Columns in the PM dropdown:

• Portfolio — Projects hub, Projects table, Work items table.
• Work & sprints — Sprints, Tasks board (Kanban), Gantt schedule.
• Dashboard — Project dashboard (portfolio KPIs).

PM links to CRM accounts and SCM projects where configured. Open the sidebar PM group for projects hub, work items, sprints, Kanban board, and Gantt.

The SCM megamenu — labeled SCM, Products, or Accounting depending on enabled modules — is the operational core for businesses that buy, stock, sell, and ship goods. Help topics are grouped in the sidebar as Buy side, Sell side, Accounting, and Storefront to match how teams think about the work.

Supply chain means the path from supplier to customer: you purchasing materials, receiving them into a warehouse, storing them in bins, picking them for orders, shipping to customers, and invoicing. inveazy records each step as a numbered document (PO-2026-0001, SO-2026-0042, etc.) so you can audit what happened and sync to QuickBooks.

Sidebar groups

• Buy side — master data (vendors, products, categories), purchase orders, receipts, and warehouse operations.
• Sell side — customers, quotes, sales orders, shipments, returns, backorders, and End-to-end workflows.
• Accounting — Accounting overview, QuickBooks setup, Stripe payments, Income & expenses, vendor bills, AP/AR exports, and customer invoices.
• Storefront — public B2B/B2C shop checkout and web-order fulfillment queue.

SCM dashboards

When Inventory is enabled, open analytics from /dashboard or the sidenav Dashboards submenu:

• Sales dashboard — booked orders, backlog, top customers/products
• Purchasing dashboard — vendor spend, open POs, open AP
• Inventory dashboard — on-hand, reorder, expiry, slow stock, variance (QTR), throughput
• Financial dashboard — P&L and GL balances (Accounting module)

Open the sidebar Buy side, Sell side, Accounting, and Storefront groups for every topic, or start with End-to-end workflows. Use Reference & glossary for PO, SO, FEFO, and accounting terms.

Hub → Hub apps → Hub overview opens the workspace landing page at /apps/workspace. If you are new to inveazy, think of this screen as the front door to collaboration tools — files, messages, calendar, assistant, and blog — rather than the place where you run sales or warehouse operations. Those live under the CRM and SCM megamenus.

This page is different from the main Applications launcher at /hub (also reachable from Admin → Dashboards → Home). The /hub launcher shows tiles for every enabled module in your workspace — CRM, PM, Inventory, Blog, and so on. The workspace landing at /apps/workspace is narrower: it groups shortcuts to hub-style apps only, organized in cards so you can jump straight to All files, Notifications inbox, Calendar, Assistant, or Blog without hunting through the full module grid.

The layout uses three columns on wide screens. The first column covers File manager entry points (all files, recent, folders, and diagnostics for administrators). The second column covers Notifications (inbox and compose) plus Calendar. The third column shows Blog hub when that module is enabled; the Workspace assistant lives in its own top-bar column and in the Assistant group in this Help sidebar. Cards you do not see mean either the module is turned off under Integrations or your role does not include access.

When to start here vs the module launcher

Use /apps/workspace when your day revolves around documents, team messages, scheduling, or content — for example an office manager checking notifications, a marketer opening the blog, or anyone grabbing a file from a shared folder. Use /hub when you need CRM, PM, SCM, or another business module and want the full tile grid. Many users bookmark one or the other depending on their job; both are valid front doors after sign-in.

For the full Hub megamenu map, see Hub menu overview. Detailed guides for each card on this page are in the sidebar Hub group: File manager, Notifications inbox, Calendar, and Blog hub. AI chat is documented under Assistant — start with Assistant overview.

Hub → Hub apps → File Manager (/apps/file-manager) is where your workspace stores uploaded documents, images, and other attachments. If you have used Google Drive, Dropbox, or a network share, the idea is familiar: folders organize files, and each file has a name, size, and owner. inveazy keeps files inside your workspace so CRM, Blog, Notifications, and other modules can reference the same library without copying bytes into every feature.

The main view lists files and folders for the tenant you are signed into. You can browse the tree, open a folder to see its contents, upload new files, download or preview existing ones, and run actions the UI exposes (rename, move, delete — depending on your role). Recent (/apps/file-manager/recent) shows files you opened or changed lately, which is handy when you are jumping between blog images and email attachments. Folders (/apps/file-manager/folders) emphasizes the folder tree for quick navigation when you already know the directory structure.

Files uploaded here are not anonymous public links by default. Other signed-in users in the same workspace see them according to permissions. When you pick a featured image for a blog post or attach a file in Notifications compose, you are usually choosing from this library. The Workspace assistant (see Assistant in this sidebar) can also reference folder names when read-only data is enabled under Integrations → AI assistant.

Stock images and blog media

Marketing and blog workflows often rely on images stored in File manager. The Blog hub lets you attach featured images and inline media from your tenant library rather than pasting random URLs. Keep a sensible folder structure — for example Marketing / Blog / 2026 — so editors can find assets quickly. Large video files are supported in some editors, but email and notification delivery may still prefer smaller attachments; test before sending to external recipients.

Diagnostics (administrators)

TenantAdmin and Admin roles see a Diagnostics entry on the workspace landing and inside File manager (?view=diagnostics). This screen runs storage and pipeline health checks — useful when uploads fail or thumbnails do not generate. It is a troubleshooting tool, not a day-to-day browse view. Regular users should use All files or Recent instead.

File manager must be enabled under Admin → Integrations → Applications. If the menu link is missing, ask your administrator to enable it or grant your role access. See also Hub overview for shortcut cards into this app.

Hub → Hub apps → Notifications (/apps/notifications) is the in-app inbox for messages sent inside your workspace. It works like a simplified email client built into inveazy: you see a list of notifications, open one to read the full body, and optionally reply or follow links to related records (a purchase order, a CRM activity, a blog post). The bell icon in the top bar also surfaces recent items, but the inbox is where you search, filter, and work through everything systematically.

Notifications are tenant-scoped. You only see messages for the workspace you are signed into. System-generated alerts — for example when an order status changes or someone assigns you a task — may appear here alongside human-written broadcasts from Compose notification. Treat the inbox as the official record of what the app told you, even if you also received email for the same event (email depends on SMTP settings under Integrations).

The hub shell uses a left sidebar for navigation. In Mail mode you get folders, labels, and search across your tenant's notification stream. Click a row to expand the message; the layout can switch to a focused reading view with thread history and action buttons at the bottom. Unread items typically stand out in the list; use filters when the volume grows after go-live.

Folders, labels, and search

Folders help you organize messages the way you would in Outlook or Gmail — for example Operations, HR, or Archived. Labels add cross-cutting tags without moving the message out of its primary folder. Search scans subjects and bodies so you can find an old announcement months later. If you are unsure where a message lives, start with search rather than clicking every folder.

Bell dropdown vs full inbox

The topbar bell is a quick preview of the latest notifications. Use it for glanceable alerts during the day. When you need to mark items read in bulk, compose a reply, or read a long HTML message with images, open the full inbox. The bell's View all link lands on this same page.

To send a new message, use Compose notification. To see dates alongside CRM tasks and PM work items, switch the sidebar to Calendar mode or open Calendar directly. Notifications must be enabled under Integrations → Applications for non-admin users to reach this URL.

Hub → Hub apps → Compose (/apps/notifications/compose) is where you write a new notification to other users in the workspace — or, when configured, to external email addresses. Think of it as send a team announcement rather than edit a customer record. Sales updates still belong in CRM; warehouse alerts might be automated from SCM, but Compose is for deliberate human messages.

The compose screen uses a rich text editor (similar to the Blog hub) so you can format headings, bullet lists, links, and embedded images. Fill in recipients — often individual users, roles, or distribution lists depending on what your administrator enabled — plus a subject line and body. A Send action stores the notification in the tenant inbox and, when SMTP is configured, may also deliver HTML email to external inboxes. Plain-text fallback is used when HTML cannot be sent.

Before your first outbound message, confirm Admin → Integrations → Email (SMTP) is set up if you expect real email delivery. In-app delivery works without custom SMTP; email to external inboxes (Outlook, Gmail, etc.) does not. Tenant SMTP overrides the host-wide mail settings when turned on. See Integrations for host, port, TLS, and from-address fields.

Images and attachments

Inline images in compose are sanitized for safe storage and email rendering. Prefer images already uploaded to File manager when possible so you are not pasting untrusted URLs. Very large images may be slow for mobile readers; resize marketing graphics before embedding. Video embeds may appear in-app but not every email client displays them — include a text link as backup.

Who can compose?

Not every role can open Compose. Your workspace administrator controls access through roles and the Notifications module toggle. If you see the inbox but not Compose, ask for a role adjustment rather than sharing your account. Composed messages appear in recipients' Notifications inbox and may trigger bell alerts immediately after send.

After sending, return to the inbox to confirm delivery or open the message thread. For automated system notifications (order shipped, invoice paid), you do not use this screen — those originate from business modules and background jobs.

Hub → Hub apps → Calendar (/apps/calendar) shows upcoming dates in one grid-style view. The goal is to answer a simple question without opening three different modules: What is happening this week? Hub calendar events sit alongside dates pulled from CRM activities and PM work items when those modules are enabled, so sales follow-ups and project deadlines can appear next to team meetings or internal reminders.

You can open Calendar from the Hub megamenu, from the workspace landing cards, or by switching the Notifications hub sidebar to Calendar mode (the Mail | Calendar toggle at the bottom of the left panel on /apps/notifications). All routes aim at the same calendar experience; pick whichever entry point matches where you already are in the app.

Calendar is a read-oriented aggregation for most users today. Creating or editing the underlying CRM activity or PM task still happens in CRM or PM screens. When you click an item, the app should take you to the source record or show enough context to decide your next step. Do not expect full project scheduling (Gantt-level detail) here — that remains under PM → Gantt.

What appears on the grid?

Typical rows include CRM activities with due dates, PM work items with target dates, and hub-native calendar placeholders as the feature matures. Color or icon cues may distinguish module sources. If a module is disabled under Integrations, its dates will not feed the calendar. Empty grids usually mean no dated items exist yet, not a broken integration.

Planning your day

A practical morning routine: open Calendar for the week view, note overdue CRM activities, check PM items due before Friday, then jump into the relevant module to do the work. Pair this with the Notifications inbox for messages that do not have a calendar date attached.

Calendar access requires the Calendar application to be enabled and your role to include hub permissions. Administrators configure modules under Integrations → Applications.

Hub → Blog → Blog hub (/apps/blog) is the editor workspace for marketing and editorial content inside your tenant. If you have used WordPress or Medium's admin screens, the split is similar: this hub is where authors write and publish; the All posts library is where readers browse finished articles. Blog is optional — enable it under Integrations → Applications and grant blog edit permissions to marketing roles.

The hub uses a three-column shell. A post list or tree on the left helps you switch between drafts and published articles. The center holds the rich text composer (Quill) for title, body, and HTML source editing. The right rail stores metadata: slug, publish state, categories, tags, featured image from File manager, SEO fields, and landing-page options tied to Public site branding. Save often; long drafts are easier to recover than retyped paragraphs.

Publishing makes a post visible to readers who can open /apps/blog/read or follow links from your public marketing site when blog integration is wired. Draft posts stay inside the hub until you explicitly publish. Preview flows let you check layout before go-live. Exact public routing (subdomain vs path) depends on branding settings and roadmap items noted in the Hub megamenu's Next sessions column.

Compose, tags, and media

Write in the rich text editor for everyday formatting — headings, lists, bold, links, block quotes. Switch to HTML source when you need precise control or paste content from the Workspace assistant (blog scope outputs Quill-friendly HTML, not Markdown). Tags and categories help organize posts for the read index filters. Featured images should be chosen from File manager so URLs stay tenant-stable.

AI-assisted drafting

The hub links to /apps/assistant?scope=blog for review and rewrite workflows. Ask the assistant to critique structure, suggest SEO improvements, or produce a draft from a topic outline — then paste the HTML back into the composer. Scoped blog data lets the assistant see existing post titles and bodies when read-only data is enabled. See Workspace assistant for BYOK, models, and report formatting rules.

Who can edit?

Only roles with blog edit permission see the Blog hub link. Readers without edit rights may still open All posts when the Blog module is enabled. Coordinate with your TenantAdmin if marketing staff need compose access but should not see SCM or CRM menus — roles are granular under Roles.

After publishing, share the read URL with stakeholders or embed links in Compose notification announcements. Future roadmap items (public area routing, RSS feeds) are placeholders in the Hub menu and are not production features yet.

Hub → Blog → All posts (/apps/blog/read) is the read-friendly index of published blog content in your workspace. Authors live in Blog hub; this page is for browsing, searching, and opening individual articles without the editing chrome. Think of it as the internal newspaper rack for your company blog.

The layout typically includes a hero area for featured stories, a searchable grid or list of posts, and sidebar widgets for categories, latest posts, and popular tags. Click a title to open the full article at /apps/blog/post/{id}. The read view focuses on typography and images — not on Quill toolbars or publish buttons.

Filtering by category or tag helps new employees find onboarding articles or product release notes. Search matches titles and excerpts so you can jump directly to a policy document or tutorial. If a post does not appear, confirm it was published in the Blog hub and that your role may view blog content (the module can be enabled for readers who cannot edit).

Readers vs editors

Users with edit permission see shortcuts back to the hub to revise a post. Pure readers stay in the library and post detail pages. This separation mirrors how many organizations give all staff read access to the internal blog but limit compose rights to marketing.

Public site relationship

Depending on Public site branding, some posts may also surface on the anonymous marketing site visitors see before sign-in. The internal read index is always available to authenticated workspace users when Blog is enabled. Public routing features on the roadmap will extend discovery (RSS, dedicated public zones) without replacing this signed-in library.

Enable Blog under Integrations → Applications. For writing workflows, pair this page with Blog hub and optional Workspace assistant drafting at ?scope=blog (documented under Assistant in this sidebar).

CRM → ORG → Organizations (/crm/organizations) is your directory of companies and legal entities — customers, partners, vendors, or prospects you track in sales. If you are new to CRM software, think of an organization as the company name on the business card, not the individual person holding it.

Organizations sit at the top of the CRM hierarchy. Under each organization you can link accounts (sell-to customer records), contacts (people who work there), leads, and opportunities (active deals). Opening an organization detail page shows related records in one place so a rep can see everything tied to "Acme Manufacturing" without searching four different lists.

The list view is a searchable table. Use Add to create a new organization with fields like name, industry, and website. Click a row to open the detail profile — a read-first page with tabs for accounts, contacts, opportunities, and (where configured) linked PM projects. Edit uses the same modal pattern as other CRM lists: click Edit in list or return to the table and open the edit modal from there.

Organizations vs accounts

An organization is the legal or commercial entity. An account is often the customer relationship you sell through — sometimes one-to-one with an organization, sometimes more nuanced when one org has multiple bill-to or ship-to accounts. When in doubt, create the organization first, then add accounts linked to it from the account detail or organization profile.

Organizations vs tenant workspaces

Do not confuse CRM organizations with tenant workspaces under Admin. A workspace is your entire inveazy environment (users, modules, settings). A CRM organization is a company inside that workspace that you sell to or partner with. See Tenant workspaces if you are setting up the platform itself.

CRM → ORG → Accounts (/crm/accounts) lists your customer accounts — the sell-to relationships your sales team manages day to day. In many small businesses, "account" simply means "customer." Each account usually links to an organization and has contacts, opportunities, and activities attached.

Accounts are where pipeline work often starts: you pick the account when creating an opportunity, set a primary contact for quotes, and filter activities by account when preparing for a call. The table view supports search and filters so reps can quickly find "Midwest Distributors" or every account owned by a teammate.

Click an account to open its detail profile — summary fields, related contacts, open opportunities, and recent activity. Create and edit happen through modals on the list page (same pattern as organizations and leads), keeping the index page focused on scanning and filtering rather than long forms.

Accounts and SCM customers

When SCM (supply chain) is enabled, CRM accounts may link to operational customer records used on sales orders and invoices. CRM is where you nurture the relationship and track the deal; SCM is where you fulfill orders and ship goods. Sales might live entirely in CRM until a quote is won, then hand off to SCM for order entry.

Typical workflow

A common path for a new customer: create an organization, add an account linked to it, add contacts for buyers and approvers, convert or create an opportunity, then log activities (calls, meetings, follow-ups) until the deal closes.

CRM → ORG → Contacts (/crm/contacts) stores people — buyers, decision makers, technical contacts, and anyone you communicate with during the sales cycle. Contacts have names, email, phone, job title, and links to an account and/or organization.

Contacts are not the same as users who sign in to inveazy. A customer's purchasing manager might exist only as a CRM contact; your colleague exists as a user under Admin. Contacts never need passwords unless you separately invite them to a portal or storefront.

The contacts list uses a card layout on smaller screens and a table on desktop — optimized for recognizing people rather than comparing numeric columns. Search by name or email, filter by account or organization, and open a contact detail page to see related opportunities and activities. When you create an opportunity, you can set a primary contact so everyone knows who to call about that deal.

Why contacts matter

Deals are won by people, not company names alone. Logging who said what — and tying activities to the right contact — prevents the classic CRM failure mode where three reps call the same buyer because nobody updated the record. Assign an owner on the contact or account when your team grows beyond one salesperson.

CRM → ORG → Leads (/crm/leads) holds prospects — people or companies you have not yet qualified as real sales opportunities. Leads often come from trade shows, website forms, referrals, or cold outreach before you know budget, timeline, or fit.

Lead records include status (for example New, Contacted, Qualified, Disqualified), source, owner, and optional links to an organization or contact. The list supports search and status filters so inside sales can work a queue of fresh inquiries each morning.

When a lead is real — they have need, budget, and authority — you qualify it: create or link an account and contact, then open an opportunity on the pipeline. Until then, keep the record as a lead so your pipeline board stays focused on deals that count toward forecast, not every business card from last week's event.

Leads vs opportunities

A lead asks: Should we pursue this? An opportunity asks: How much might we win, and when? Opportunities have stages, amounts, and expected close dates used on the pipeline Kanban and CRM dashboard. Do not skip leads entirely if your process needs a qualification step — but do not clutter the pipeline with unqualified names either.

CRM → Pipeline → Pipeline (/crm/pipeline) is a Kanban board for opportunities — your visual sales funnel. Each column is a stage (such as Qualification, Proposal, Negotiation, Closed Won). Each card is one deal you can drag between stages as it progresses.

Kanban is a simple idea from manufacturing: work flows left to right (or top to bottom) through defined steps. In sales, the pipeline board answers Where is every deal stuck? at a glance. Managers scan column totals; reps drag cards after customer meetings instead of opening spreadsheets.

The board supports search and account filters so you can focus on one customer or rep. Click a card to open the opportunity detail page for amount, close date, line items, and related activities. Use New opportunity on the board header to create a deal without leaving the visual view. Switch to Table view (Opportunities) when you need sortable columns, bulk scanning, or export-friendly layouts.

Stages and forecasting

Stages are configured for your workspace (often by an admin). Early stages represent exploratory work; later stages mean a proposal is out or legal is reviewing. Expected close date and amount on each opportunity feed the CRM dashboard (/dashboard/crm) for funnel value and stage distribution charts.

Pipeline vs activity board

The Pipeline board tracks deals by sales stage. The Activity board (Activity board) tracks tasks and touchpoints (calls, meetings, to-dos) by activity type. Use both: pipeline for revenue motion, activity board for daily execution.

CRM → Pipeline → Opportunities (/crm/opportunities) is the table list of active deals — the same opportunity records shown as cards on the Pipeline Kanban, presented for sorting, filtering, and fast lookup.

An opportunity ties together an account (and often a primary contact), a stage, an estimated amount, probability or status, and an expected close date. Detail pages show line items when you quote products, related activities, and links back to the account and contact profiles. Edit opens from the list via modal, matching other CRM master lists.

Use the opportunities table when you need to answer questions like: Which deals close this month? Everything over $50k in Proposal stage? All opportunities for organization X? Use the pipeline board when you want to move deals visually during a pipeline review meeting.

When a deal closes

Moving an opportunity to Closed Won marks sales success in CRM. Fulfillment — purchase orders, projects, invoices — typically continues in SCM or PM depending on what you sold (physical goods vs a services engagement). CRM remains the historical record of how the customer relationship started.

CRM → Pipeline → Activity board (/crm/activities/board) is a Kanban view for activities — calls, emails, meetings, tasks, and other follow-ups — grouped by activity type rather than by sales stage.

Sales work is two rhythms: moving deals forward (pipeline) and doing the daily follow-ups that make deals move (activities). The activity board helps reps see "all my calls due today" or "meetings waiting to be scheduled" in columns, similar to how the pipeline board shows deals by stage.

Activities can link to an account, contact, lead, or opportunity so context travels with the task. Drag cards between columns when status changes (for example from Planned to Completed). Deep links from opportunity detail pages can open the board filtered to that deal's open activities.

Activity board vs activities list

The Activities list (/crm/activities) is a flat, filterable table — better for searching subject lines, due dates, or owners across hundreds of rows. The activity board is better for doing today's work in a visual queue. Many teams start the day on the board and switch to the list for reporting.

CRM → Pipeline → Activities (/crm/activities) is the master list of tasks and touchpoints — every logged call, meeting, email reminder, or to-do tied to your sales records.

Activities are the memory of your customer relationships. Without them, CRM devolves into a phone book with dollar amounts. With them, any rep can see that someone called last Tuesday, a demo is scheduled Friday, and a proposal follow-up is overdue. Each activity has subject, type, status, due date, owner, and optional links to account, contact, lead, or opportunity.

The list supports pagination, search, and filters (status, type, related records). Create new activities from the list or from opportunity and account detail pages so logging happens in context. Completed activities stay in history — they are not deleted — so handoffs between reps stay auditable.

Building a daily habit

A lightweight CRM discipline that works for small teams: end every customer interaction by creating or completing an activity; start each morning by filtering activities due today. Pair this list with the Activity board when you prefer columns over rows.

CRM → Dashboard & navigation → Deals (/crm/organizations/overview) is an organization-centered deal view — a card grid of companies with shortcuts into their accounts, contacts, opportunities, and pipeline work.

Where the pipeline board organizes by stage and the opportunities table organizes by deal rows, Deals organizes by customer company. It answers: For each organization we sell to, what is happening right now? Each card surfaces key metadata and links so you can jump into the right list without starting from global search.

This view suits account managers and owners who think in terms of named customers ("everything about Contoso") rather than individual opportunity IDs. Search filters the card grid by name, industry, or website. From a card you can drill into organization detail, open related opportunities, or switch to the organizations table for bulk admin work.

Deals vs pipeline

Use Pipeline for stage-based funnel reviews and drag-and-drop progression. Use Deals when your mental model is the customer portfolio — especially when one organization has multiple concurrent opportunities or cross-sell threads.

CRM → Dashboard & navigation → CRM Home (/crm) is the CRM navigation hub — a landing page that mirrors the CRM megamenu in three columns: ORG, Pipeline, and Dashboard & navigation.

If you are new to inveazy CRM, start here after sign-in. Each tile explains a module in one sentence and links to the live screen. You do not manage data on the home page itself; it orients you the same way the top bar dropdown does, but with room for short descriptions and counts when the overview API loads summary numbers.

Experienced users often bookmark deeper pages (/crm/pipeline, /crm/contacts) and skip home. New users and occasional CRM visitors benefit from the hub when they forget whether "Deals" or "Pipeline" is the Kanban view. For analytics, use CRM dashboard (/dashboard/crm) linked from the third column — charts and KPIs, not navigation tiles.

Suggested learning path

1. Read CRM menu overview for the big picture.
2. Set up Organizations and Accounts for your top customers.
3. Add Contacts and capture inbound names as Leads.
4. Create opportunities and work them on the Pipeline; log follow-ups in Activities.

PM → Portfolio → Projects hub (/pm) is the PM home page — a launcher with tiles for every major project-management screen in inveazy. If you have never used project software before, start here to see how the pieces fit together before diving into a specific list or board.

Project management (PM) is about delivering agreed work on time — internal initiatives, client implementations, product releases, or service engagements. Unlike CRM (which tracks who might buy), PM tracks what your team must build or deliver after the sale or alongside operations. The hub does not hold task data; it routes you to overview KPIs, project tables, work items, sprints, the Kanban board, and the Gantt chart.

The card order matches the PM megamenu: portfolio screens first, then execution tools (work items, sprints, board, schedule). Bookmark /pm if you split time between modules and want a neutral re-entry point into PM.

PM vs CRM

CRM opportunities represent revenue potential; PM projects represent delivery commitments. A consulting firm might win a deal in CRM, then create a PM project linked to the customer organization to track milestones and hours. Manufacturing might use PM lightly for plant improvement while SCM handles inventory. See CRM menu overview for the sales side.

PM → Portfolio → Projects (/pm/projects) is the master table of projects in your workspace. A project is a container — a named body of work with a code, status, owner, start and end dates, and optional links to a CRM organization or account when the engagement is customer-facing.

Think of a project as a folder that holds hundreds of work items (tasks, bugs, stories, chores). Examples: "Website redesign Q3," "Acme ERP rollout," or "Warehouse WMS phase 2." Without projects, work items would be an undifferentiated pile; with them, teams filter noise and report progress per initiative.

The table supports search and status filters. Click a row to drill into that project's work items or open project context on other PM screens. Create projects from the list when a new engagement starts; archive or complete them when delivery ends so dashboards stay honest about active load.

Projects vs work items

Projects answer What initiative is this part of? Work items (Work items) answer What specific task must someone do? You almost always pick a project before creating or filtering work items, sprints, or board columns.

PM → Portfolio → Work items (/pm/work-items) is the table view of tasks — the atomic units of project work. Each work item has a title, type, status, priority, assignee, sprint (optional), and parent project.

If you are new to PM tools, "work item" is a neutral term for anything trackable: a developer's bug fix, a consultant's deliverable, a marketing asset, or a facilities ticket. Items move through statuses (To Do, In Progress, Done, and your workspace's custom values) either on this table or on the Tasks board.

Select a project (and optionally a sprint) at the top of the page to scope the grid. Click a row to open the detail screen for description, comments, dates, and links. Use the table when you need sortable columns, bulk scanning, or to find one item by keyword across a large backlog.

Backlog vs sprint items

Items not yet assigned to a sprint live in the backlog — a holding area for future work. During sprint planning, teams pull items from the backlog into the active sprint. The same work item record travels; only the sprint field changes. See Sprints for time-boxing.

PM → Work & sprints → Sprints (/pm/sprints) lists sprints — fixed time boxes (often one or two weeks) during which the team commits to completing a set of work items. Sprints come from agile software development but work for any team that plans in short cycles.

Each sprint row shows name, date range, project, and counts of items (open, completed, total). Sprints give rhythm: plan on Monday, demo on Friday, retrospect what blocked you. Without sprints, backlogs grow forever; with them, you force prioritization conversations.

From the sprint table you can jump to the Tasks board or Work items filtered to that sprint. Creating a sprint is usually a lead or scrum-master action at the start of a cycle; individual contributors then pick up assigned items during the sprint.

Do you need sprints?

Small teams doing ad-hoc tasks can leave everything in the backlog and use the Kanban board without formal sprints. Sprints help when capacity planning, stakeholder demos, or velocity metrics matter. inveazy supports both modes — choose what matches your culture.

PM → Work & sprints → Tasks board (/pm/board) is a Kanban board for work items — columns represent status (To Do, In Progress, Review, Done), and cards represent individual tasks you drag as work advances.

Kanban visualizes flow: work enters on the left, exits on the right when complete. Stand-up meetings often happen in front of this board — each person moves their cards and calls out blockers. It is the execution counterpart to the Work items table, which is better for search and sorting.

On page load, pick a project and optionally a sprint — the board is always scoped so you are not mixing unrelated initiatives. Cards show assignee, priority, and title; click through for full detail. Drag-and-drop updates status immediately for the team.

Tasks board vs CRM pipeline

Both use Kanban columns, but they track different objects. CRM Pipeline moves sales opportunities by deal stage. PM Tasks board moves delivery work items by task status. Sales and delivery teams can each have a board without sharing columns.

PM → Work & sprints → Gantt (/pm/gantt) shows a schedule chart for one project — work items plotted on a timeline with start dates, end dates, and dependencies where configured.

Gantt charts answer When does each piece happen, and what blocks what? They suit waterfall-style planning, client milestones, or any project where executives expect a calendar view rather than a Kanban column. A long implementation might show design finishing before development starts, with testing trailing construction.

Select the project at the top of the page. Bars represent work items; dragging or editing dates updates the schedule (subject to your permissions). Use Gantt for stakeholder communication and deadline risk; use the Tasks board for daily team execution. Many teams live on the board during the week and review Gantt in monthly status meetings.

Keeping the schedule honest

Schedules drift when dates are set once and never updated. Treat Gantt as a living document: when a task slips on the board, adjust its dates here so portfolio dashboards and the Project dashboard (/dashboard/projects) reflect reality.

Suggested PM workflow

1. Create a Project for the initiative.
2. Break work into Work items; optionally group a cycle in a Sprint.
3. Execute daily on the Tasks board; communicate dates on Gantt.
4. Monitor portfolio health on the project dashboard and /pm/overview when you need KPIs across many projects.

SCM → Products & Vendors → Overview (/inventory) is the signed-in landing hub for supply chain work. If you are new to ERP (Enterprise Resource Planning) or WMS (Warehouse Management System) software, start here after reading the SCM menu overview. This page orients you to what your workspace can do — catalog only, full warehouse execution, or accounting — before you open purchase orders or pick lists.

The overview hub typically surfaces shortcuts into the megamenu columns you see in the top bar: master data (vendors, customers, products), operational documents (POs, SOs, receipts, shipments), warehouse screens (on-hand, transfers, cycle counts), and finance slices when Accounting is enabled. What appears depends on modules turned on under Admin → Integrations → Applications and on your role.

Think of SCM as the operational mirror of your physical business: you buy from suppliers, store goods, sell to customers, and record money owed and owed to you. CRM tracks the relationship before the deal closes; SCM tracks what happens after — stock moves, documents get numbered, and (optionally) journals post to your general ledger or QuickBooks.

Use this hub when you are not sure which SCM screen to open next. Purchasing staff often jump to Purchase orders or Receipts; warehouse staff to On-hand inventory, Reorder alerts, or Mobile scanner; finance to Invoices and Vendor bills. The Reference & glossary section defines acronyms used throughout SCM.

SCM → Products & Vendors → Vendors (/inventory/vendors) is your supplier directory — companies you buy from. A vendor record holds the name, remit-to address, default payment terms, tax identifiers, and contacts you need when raising a PO (purchase order) or recording an AP (accounts payable) bill.

In small businesses the vendor list might be dozens of rows; in distribution it can be hundreds. Each vendor is master data: it does not move inventory by itself. You reference a vendor on purchase orders, receipts, and vendor bills so spend rolls up correctly on the purchasing dashboard and in AP aging reports.

Set up vendors before your first PO. Capture lead times and preferred currency if you buy internationally. When Accounting is enabled, vendor terms (Net 30, Net 15, and so on) drive due dates on bills and help finance prioritize Vendor bills for payment. Linking a vendor to the right default expense or inventory accounts happens during integration setup — see Integrations for QuickBooks mapping.

Vendors are not CRM organizations, though the same real-world company might exist in both places: CRM for the relationship conversation, SCM for purchase documents. Keep vendor codes and names consistent so three-way match (PO, receipt, bill) is easy for your bookkeeper. See Purchase orders for the buy-side document flow.

SCM → Products & Vendors → Customers (/inventory/customers) lists sell-to accounts used on sales orders, quotes, shipments, and customer invoices. Where CRM tracks pipeline and contacts, SCM customers carry operational fields: ship-to and bill-to addresses, credit terms, tax exemption flags, and default price lists for SO (sales order) entry.

Every outbound document that represents revenue should point at a customer record so AR (accounts receivable) aging and regional sales dashboards stay accurate. Web storefront checkouts also resolve to SCM customers (or guest flows that create them) so web orders can fulfill like desk-entered orders.

Create customers before quotes or sales orders. If you already maintain CRM accounts, align names and links so sales does not duplicate "Acme Corp" three times. Credit limits and hold flags (when present) prevent shipping when a buyer is past due — finance and operations share the same customer truth.

Customer master data feeds Quotes, Sales orders, Shipments, and Invoices. Exported AR batches push invoice totals to QuickBooks when configured under Integrations. For the sell-side story end to end, read End-to-end workflows.

SCM → Products & Vendors → Products (/inventory/products) is your tenant SKU (Stock Keeping Unit) catalog — the items you buy, stock, and sell. Each product has a code, description, unit of measure, pricing, and (when Inventory is enabled) warehouse behavior such as lot tracking or default pick locations.

Products are the hinge between every SCM document. Purchase order lines, sales order lines, receipt lines, shipment lines, and invoice lines all reference the same SKU so quantities and costs stay consistent. A consumable is a product you use up rather than resell — shop supplies, packaging, or floor cleaner — often expensed on receipt instead of held as inventory; your bookkeeper sets that treatment per item or category.

The list view is a searchable grid for operators; add and edit open dedicated pages or modals when many fields are involved (dimensions, barcodes, images, vendor part cross-references). Enable Products alone for catalog and storefront pricing without warehouse screens; enable Inventory to track on-hand balances and run pick/pack workflows.

Organize products with Categories and optionally seed from the shared Product catalog. Before high-volume receiving, confirm each SKU has a unit of measure and (if you pick by location) a sensible default bin under Locations.

SCM → Products & Vendors → Product catalog (/inventory/products/catalog) exposes the platform master catalog — shared product definitions (often keyed by a master Inv#) that tenants can adopt instead of typing every field from scratch. If you have managed a distributor price book or industry data feed, the idea is similar: one canonical description, many workspaces copying what they sell.

Adoption copies master attributes into your tenant product list while keeping your local SKU codes, prices, and warehouse settings editable. This reduces onboarding time for new tenants and keeps naming consistent when multiple branches sell the same manufactured part.

Use the catalog when you are standing up a new workspace or expanding into a product line you do not yet maintain locally. After adoption, treat rows in Products as yours — adjust pricing, enable or disable storefront visibility, and assign categories. The catalog does not replace day-to-day edits on your live SKU list.

Catalog availability depends on host configuration and your Products module access. If you do not see expected master items, ask your TenantAdmin whether catalog sync is enabled. For terminology on SKU and consumables, see Reference & glossary and Products.

SCM → Products & Vendors → Categories (/inventory/categories) defines a hierarchical tree for grouping products — for example Hardware → Fasteners → Bolts. Categories help buyers browse the storefront, filter long product grids, and apply defaults (GL accounts, tax rules, or reporting buckets) consistently.

Unlike a flat tag list, parent/child categories preserve navigation breadcrumbs on the public store and in internal lists. Plan the tree early: reorganizing thousands of SKUs later is tedious. Many teams mirror their website navigation or their supplier's catalog structure.

Each product links to one primary category (and optionally secondary groupings depending on configuration). Purchasing reports and dashboards can slice spend by category when line items inherit the product's classification. Warehouse staff may still pick by SKU or bin regardless of category — categories are primarily a catalog and analytics tool.

Maintenance is an admin-style lookup table: search, add, edit, and drag to reparent nodes where the UI supports it. Pair category setup with Products import or Product catalog adoption so new items land in sensible branches from day one.

SCM → Purchasing & Sales → Purchase orders (/inventory/purchase-orders) is where you authorize spending with suppliers. A PO (purchase order) is a formal request: vendor, ship-to warehouse, line quantities, unit costs, and expected dates. It does not by itself increase on-hand stock — receiving does — but it commits your business to buy and gives the warehouse something to expect on the dock.

Typical statuses flow from draft → approved → partially received → closed. Buyers create POs from approved requisitions or ad hoc when stock is low. Link each line to a product SKU and quantity; optional project or department dimensions may exist for job-costing shops. Document numbers (PO-2026-0001) are audit-friendly handles referenced on receipts and vendor bills.

When goods arrive, warehouse staff post a Receipt against the PO so received quantities update on-hand balances and accrue inventory value for later three-way match (PO quantity/price, receipt quantity, vendor invoice amount). Short shipments leave PO lines open and may spawn Backorders on the buy side.

Open PO value appears on the SCM purchasing dashboard. Finance uses approved POs to control spend before AP posts. For the full buy-side chain PO → receive → bill → QuickBooks, see End-to-end workflows and Vendor bills.

SCM → Purchasing & Sales → Sales orders (/inventory/sales-orders) captures customer demand you intend to fulfill. An SO (sales order) lists ship-to customer, requested dates, line SKUs, quantities, and pricing — the operational counterpart to a CRM won deal or a accepted Quote.

Sales orders reserve or allocate inventory depending on configuration, drive pick lists, and feed shipment and invoice creation. Status columns tell warehouse and customer service where each order stands: open, picking, partially shipped, closed. Unlike a quote, an SO is a commitment to deliver and often triggers revenue recognition timing when invoiced.

Enter SOs from inside sales, customer service, or by converting quotes and web orders. Each line should reference a live product with sufficient on-hand or an explicit backorder path. Mobile scan workflows (where enabled) let pickers confirm quantities by barcode against SO lines.

After picking, create a Shipment to decrement stock and record carrier tracking, then an Invoice for AR. The sell-side narrative is spelled out in End-to-end workflows. Ensure Customers and Products exist before high-volume SO entry.

The Storefront is your workspace’s customer-facing shop — anonymous or signed-in buyers browse Products organized by Categories, add lines to a cart, and check out. Paid or approved orders land in Web orders for the same pick/ship/invoice pipeline as desk Sales orders, without a Quote step.

Storefront work spans three areas: catalog (what is visible and priced online — see Buy side product topics), checkout (Stripe payments under Accounting and public site branding under Public site branding), and fulfillment (web orders queue after payment). Operations staff should monitor on-hand in On-hand inventory so the store does not oversell.

Topics in this group

• Web orders — storefront checkout queue and fulfillment actions

Master data and warehouse execution live under Buy side and Sell side; finance topics (QuickBooks, Stripe, income & expenses) live under Accounting in the help sidebar. For the full quote-to-cash story including storefront, read End-to-end workflows.

SCM → Purchasing & Sales → Web orders (/inventory/web-orders) lists orders placed through your public storefront — the customer-facing shop tied to your workspace. Shoppers add SKUs to a cart, checkout with payment or account terms, and the order lands here for the same fulfillment pipeline as desk-entered sales orders.

Web orders bridge e-commerce and WMS execution. Operations staff review payment status, fraud holds, and ship-to addresses before releasing pick work. Many rows auto-map to underlying SO documents; others may stay in a web-specific status until a CSR confirms stock. Email notifications (order confirmation, shipment) depend on SMTP settings under Integrations.

Storefront visibility comes from product and category setup in Products plus public site branding in Admin. Inventory availability shown online should reflect On-hand inventory minus allocations so you do not oversell. Stripe for checkout is configured via stack Stripe__* and Integrations → Providers → Payments.

Treat web orders as the entry point for B2C or lightweight B2B self-service. Returns from the store flow into Returns (RMA). For quote-driven B2B sales that never touch the cart, use Quotes and Sales orders instead.

SCM → Purchasing & Sales → Quotes (/inventory/quotes) holds proposals — priced line items for a prospect or customer before anyone commits inventory or revenue. Quotes carry expiration dates, optional discounts, and ship-to hints so sales can iterate without creating a live SO.

In ERP language a quote is non-posting: it does not move stock or GL balances. When the buyer accepts, convert the quote to a SO in one action, carrying lines and pricing forward. That conversion is the handoff from sales negotiation to warehouse fulfillment documented in End-to-end workflows.

Quotes complement CRM opportunities: CRM may track stage and probability; SCM quotes hold SKU-level detail ready for pickers. Align customer records between CRM accounts and SCM customers so conversion does not require retyping addresses.

Print or email quote PDFs using letterhead from Admin → My organization. Revise quotes by versioning or editing draft rows depending on your process. Lost quotes simply expire; won quotes become sales orders and may spawn partial shipments over time.

SCM → Purchasing & Sales → Receipts (/inventory/receipts) records inbound goods — what actually arrived on the dock against a PO or ad hoc. Receiving is the moment on-hand inventory increases (for stock items) and accrued liability may start for later AP matching.

Warehouse staff verify vendor packing slips against PO lines, enter received quantities, and optionally capture lot numbers, serials, or expiration dates for FEFO (First Expire, First Out) picking — ship or consume the oldest expiry first to reduce waste. Putaway directs stock into a target warehouse and bin (Locations).

Partial receipts are normal: close PO lines only when fully received or explicitly cancelled. Over-receipts should be flagged before posting so three-way match stays clean when the vendor bill arrives. Mobile receiving (scan workflows) speeds high-volume SKUs when Inventory mobile is enabled.

Receipts tie forward to Vendor bills and backward to Purchase orders. Finance expects received quantity × PO cost to approximate the bill. See On-hand inventory for balances after posting and End-to-end workflows for the PO leg.

SCM → Purchasing & Sales → Shipments (/inventory/shipments) documents outbound fulfillment — cartons leaving the warehouse against a sales order or web order. A shipment records what was picked, packed, weighed, and handed to a carrier, with tracking numbers for customer service.

Operationally, shipment posting decrements on-hand at the source bin and marks SO lines shipped. Partial shipments are common in backorder situations: ship what you have today, leave remaining quantity open for a later shipment or Backorder release when stock arrives.

Pickers may use paper pick lists or mobile scan confirmation depending on your setup. Capture package count and freight method for rate shopping audits. Shipment documents are the proof operations needs when a customer asks "did you ship my order?" before AR sends the invoice.

Shipments sit between Sales orders and Invoices in the quote → SO → pick → ship → invoice chain (End-to-end workflows). Returns reverse portions of this flow through Returns (RMA).

SCM → Purchasing & Sales → Returns (RMA) (/inventory/returns) manages customer returns — goods coming back after a shipment or store purchase. An RMA (Return Merchandise Authorization) is the controlled authorization number and document that tells the warehouse what to expect and whether to restock, scrap, or credit the buyer.

Returns reverse pieces of the outbound flow: received return quantity may increase on-hand in a quarantine or resale bin, trigger a credit memo against AR, or route to vendor warranty for supplier RMA. Link returns to the original SO or web order when possible so quantities and pricing match what the customer actually received.

Customer service creates the RMA with reason codes (defective, wrong item, changed mind). Warehouse inspects upon receipt — not every unit returns to sellable stock. Finance coordinates refund timing with payment processor or credit on account.

Store-initiated returns from Web orders land in the same queue. For terminology on AR credits, see Invoices and Reference & glossary. Sell-side and return paths together are summarized in End-to-end workflows.

SCM → Warehouse operations → Warehouses (/inventory/warehouses) defines physical or logical stocking sites — main DC, retail back room, 3PL partner site. Every on-hand balance, receipt, shipment, and transfer is scoped to a warehouse so multi-site businesses do not commingle quantities.

Create at least one warehouse before receiving or transferring stock. Each warehouse has an address used on PO ship-to lines and may have default picking strategies. Users and roles can restrict which warehouses appear for a given clerk — a store associate might only see the retail warehouse, not the central DC.

Warehouses contain bins (Locations): aisles, shelves, staging lanes, and quarantine areas. WMS discipline means "no bin, no pick" — even a single-site shop benefits from a RECEIVING and SHIPPING staging bin to keep counts honest during busy days.

Warehouse master data underpins On-hand inventory, Transfers, and Cycle counts. Enable Inventory under Integrations before these screens appear in the megamenu.

SCM → Warehouse operations → Locations (/inventory/locations) lists bins, zones, and shelves inside a warehouse — the smallest address pickers use when they walk the floor. A bin code like A-03-02 (aisle-rack-level) tells staff exactly where a SKU lives.

Locations enable bin-level on-hand, directed putaway, and cycle counts by zone. Without bins, inventory may still exist at warehouse level only, but accuracy suffers as SKU count grows. Staging bins (RECV, PACK, SHIP) separate in-transit quantities from sellable shelf stock.

Define locations before high-volume receiving so putaway rules have targets. Some products require temperature-controlled or hazmat bins; note that in location descriptions for training. Barcode labels on bins pair with mobile scan pick and count apps.

On-hand balances by bin appear under On-hand inventory. Transfers may move stock bin-to-bin within a warehouse or warehouse-to-warehouse via Transfers. See Warehouses for site setup first.

SCM → Warehouse operations → Inventory (/inventory/on-hand) shows quantity on hand by product, warehouse, and (when tracked) bin. This is the operational truth pickers and buyers consult — not the same as CRM pipeline or PO open quantity, but the net physical (or system-tracked) stock available to promise.

On-hand changes when you post receipts, shipments, transfers, adjustments from cycle counts, and approved returns. Allocations against open SOs may reduce available quantity even while on-hand remains until shipment posts. Learn both columns if your grid exposes allocated vs free balance.

Lot and expiry tracking supports FEFO picking for perishables — the system suggests the bin with the soonest expiration. Non-stock consumables may never appear here if you expense them on receipt rather than carrying inventory.

Use this screen for daily stand-ups: what is out of stock, what is overstuffed, which bin to count next. Drill into transaction history from product detail when investigating discrepancies. Pair with Cycle counts to correct drift and Backorders when available quantity cannot cover SO lines.

SCM → Warehouse operations → Transfers (/inventory/transfers) moves stock between warehouses or bins without a customer sale or vendor purchase. Retail replenishment (DC to store), consolidating partial bins, or sending demo units to a trade-show warehouse are everyday transfer scenarios.

A transfer document lists source and destination, SKUs, and quantities. Posting decreases on-hand at the origin and increases at the destination in one coordinated transaction, preserving total enterprise quantity. In-transit status may apply when a truck is between sites overnight.

Transfers do not create revenue or AP by themselves — they are internal logistics. Mis-posted transfers are a common reason cycle counts disagree; always confirm bin barcodes when scanning. Large transfers may require approval roles similar to PO approval.

Setup requires at least two Warehouses or multiple Locations. Verify results on On-hand inventory after posting. For external inbound/outbound, use Receipts and Shipments instead.

SCM → Warehouse operations → Cycle counts (/inventory/cycle-counts) supports physical inventory counts on a rolling schedule — count aisle A this week, aisle B next — instead of shutting down the entire warehouse for an annual wall-to-wall count.

Supervisors create count batches by warehouse, zone, or product class. Counters enter scanned or keyed quantities per bin; the system compares to expected on-hand and highlights variance. Approved adjustments post inventory corrections and may feed GL adjustment entries when Accounting is enabled.

Good cycle count hygiene treats variance as a process signal: receiving errors, unposted shipments, theft, or unit-of-measure mistakes. Investigate large deltas before accepting adjustments. Freeze picking on a bin while counting if your process requires it.

Cycle counts complement — not replace — transaction discipline on Receipts, Shipments, and Transfers. See On-hand inventory for balances before and after reconciliation.

SCM → Warehouse operations → Backorders (/inventory/backorders) lists order lines that could not be fully picked because available stock was short — or, on the buy side, PO lines not yet received. Backorder queues help customer service set expectations and help buyers chase vendors.

When pickers short-ship an SO, remaining quantity often stays open as backordered until replenishment arrives. FIFO (first in, first out) or FEFO allocation rules determine which waiting orders get stock first when a receipt posts. The purchasing dashboard may highlight PO lines overdue to receive that block sales.

Proactive backorder management reduces cancel rates: notify customers of delays, swap equivalent SKUs when allowed, or partial ship with consent. Finance should know backordered revenue is not yet invoiced — AR follows shipment, not SO entry.

Clear backorders by receiving against Purchase orders, transferring from another Warehouse, or adjusting demand on the Sales order. See End-to-end workflows for how backorders sit in the fulfillment chain.

inveazy Accounting is the finance slice of SCM: you run warehouse and sales operations here, record money in and out, and optionally keep QuickBooks Online (QBO) aligned as your accountant’s system of record. inveazy is not a full QuickBooks replacement — it gives you operational AR/AP, a lightweight general ledger (GL) in SQL (Acct_Journal), and controlled export/sync to QBO. Stripe is the card-payment rail for customer invoices and storefront checkout; inveazy never stores card numbers.

Enable the Accounting module and connect providers under Admin → Integrations. Each workspace connects its own QBO company and Stripe account. After changes, use Sync status on that screen to confirm exports succeeded.

Three layers: operations, local GL, QuickBooks, Stripe

Think of four cooperating pieces:

1. SCM documents — purchase orders, receipts, shipments, vendor bills, and customer invoices. These mirror what happened in the warehouse and on the sales desk.
2. Local GL — balanced journal entries posted in inveazy when you approve documents or record payments. You can report in-app (finance dashboards, GL queries) without opening QuickBooks every day.
3. QuickBooks Online — optional but typical for small businesses. Master data (products, vendors, customers) and subledger documents (Bills, Invoices, Payments) sync or export to QBO. Your bookkeeper reconciles bank accounts and runs formal financial statements there.
4. Stripe — optional card collection. Customers pay on a Stripe-hosted checkout page; webhooks tell inveazy the invoice is paid. Processing fees are tracked for GL and can be reflected in QBO without double-counting revenue.

Sell side (simplified):
  Quote → Sales order → Shipment → Invoice
    │                              ├─ Local GL: DR Accounts Receivable / CR Revenue (+ tax)
    │                              ├─ QBO: Invoice (via AR export batch or direct sync)
    │                              └─ Customer pays → Stripe Checkout OR check/ACH recorded in-app
    │                                     ├─ Local GL: clear AR to Cash (fee split if Stripe)
    │                                     └─ QBO: Payment on Invoice (+ fee entry if Stripe)

Buy side (simplified):
  PO → Receipt → Vendor bill
    │       ├─ Local GL: inventory / GR-IR on receipt (when enabled)
    │       └─ QBO: Bill (via AP export batch or direct sync)
    └─ You pay vendor in bank / QBO Bill Pay (outside inveazy)

Outside PO/SO:
  Income & expenses (cash entry) → Local GL → QBO Purchase (expense) or Deposit (income)

Income & expenses (Acct_CashEntry)

Income & expenses (/inventory/cash-entries) is for money that does not belong on a formal vendor bill or customer invoice — petty cash, bank service charges, a one-off consulting deposit, or a quick office supply run without a PO. Each entry is either expense or income, with:

• A category account (expense or revenue line on your chart).
• A money account (bank or cash — e.g. operating checking).
• Amount, date, payee/party, memo, and optional link to a CRM customer on income rows.

Workflow: save as draft, then post. Posting creates a balanced local journal — expense posts DR category / CR money; income posts DR money / CR category. If QuickBooks is connected, the entry syncs as a native QBO Purchase (expense) or Deposit (income), not as a duplicate journal entry. Edits to a posted entry update both the local journal and the existing QBO transaction on re-sync.

Use Vendor bills and Invoices when you need open AP/AR aging, three-way match, or ties to PO/SO lines — not cash entries.

Accounts receivable — invoices, exports, and Stripe

When you issue a customer invoice from fulfilled sales (or a storefront order), inveazy records what the customer owes:

• Local GL at invoice — typically debits Accounts Receivable and credits sales revenue (and sales tax payable when applicable). Shipment posting may also move COGS and inventory when inventory accounting is enabled.
• QuickBooks — approved invoices export through AR export batches (or sync on demand). Customers, items, and tax accounts must map to QBO first — configure under Integrations.
• Stripe payment — when Stripe is enabled, sending an invoice email can create a Stripe Checkout link (checkout.stripe.com). The customer pays on Stripe’s page; a webhook marks the invoice paid in inveazy. Local GL then records cash received net of Stripe’s processing fee (fee booked to a merchant-fees expense account). QuickBooks receives a native Payment against the invoice for the gross amount, plus a separate fee entry — the app avoids pushing the full cash-receipt journal twice so QBO does not double-count AR.
• Non-Stripe payment — check, ACH, wire, or cash recorded manually clears AR in the local GL (DR bank / CR AR). QuickBooks payment recording for manual methods may be completed in QBO; the local books still reflect the receipt for in-app reporting.

Storefront Web orders follow the same pattern: order → shipment → invoice → Stripe checkout at checkout or invoice email, depending on terms.

Accounts payable — vendor bills and export batches

On the buy side, a vendor bill records what you owe after goods or services arrive. Match it to the PO and receipt when possible (three-way match). Approved bills roll into AP export batches and become QBO Bills. You pay suppliers in your bank portal or QuickBooks Bill Pay; inveazy tracks approval and open balance until export and payment are reflected in QBO.

Receipt posting may capitalize inventory or expense consumables immediately depending on product setup — see End-to-end workflows for the PO → receive → bill chain.

Avoiding double-counting in QuickBooks

inveazy deliberately separates native QBO documents from journal-only events:

Event in inveazy	Local GL	What goes to QuickBooks
Customer invoice	Yes — AR / revenue	QBO Invoice (not the same journal again)
Vendor bill	Yes — AP / expense or inventory	QBO Bill
Income / expense cash entry	Yes	QBO Purchase or Deposit
Stripe invoice payment	Yes — cash, fee, clear AR	QBO Payment + fee entry (not duplicate cash journal)
Cycle count variance, some adjustments	Yes	QBO Journal entry (no native document)

If Sync status shows errors, fix account or name mapping, then Re-sync. Common failures: missing QBO bank account for cash entries, customer not synced before an AR deposit, or item/account mismatch on bills.

Typical month-end rhythm

1. Close warehouse activity — finish shipments and receipts for the period.
2. Post stray cash items in Income & expenses.
3. Approve vendor bills and invoices; run AP and AR export batches to QuickBooks.
4. Confirm Stripe-paid invoices show paid and check Sync status for QBO payments and fees.
5. Reconcile bank and QBO in QuickBooks (official statements) — inveazy operational totals should align with exported documents.

Where to read next

• Income & expenses — day-to-day cash in/out outside PO/SO.
• Stripe payments — platform vs tenant commerce, checkout, webhooks.
• QuickBooks setup — OAuth checklist and troubleshooting.
• Invoices and AR export batches — money customers owe you.
• Vendor bills and AP export batches — money you owe suppliers.
• End-to-end workflows — sell-side and buy-side document chains.
• Integrations — Stripe, QuickBooks OAuth, sync status, module toggles.
• Reference & glossary — AR, AP, GL, COGS, export batch definitions.

Stripe in inveazy serves two separate purposes. Do not mix them — they use different accounts, keys, and webhooks.

World	Who pays whom	Where configured	Typical use
Platform SaaS billing	Tenants pay you (the host) for inveazy subscription	Demo / billing host Stripe__* only — never paste these into a customer install	Admin billing Checkout / Customer Portal; webhook /api/billing/stripe/webhook on that host
Tenant commerce	Your customers pay your business for invoices and web orders	Stack env Stripe__* for that install (what checkout uses today) + Admin → Integrations → Providers → Payments for keys checklist and webhook URL	AR invoice pay links, storefront checkout; card data stays on Stripe

This guide focuses on tenant commerce — the Stripe account for buyers paying invoices and web orders. See Accounting overview for how paid invoices post to GL and QuickBooks.

What you configure where

• Stack / Dockhand env (Stripe__SecretKey, Stripe__PublishableKey, Stripe__WebhookSecret, optional Connect secret) — required for checkout and webhook verification at runtime. New provisions should leave these blank (or use shared test keys) until the customer supplies their own account — do not copy Hivoltech live keys into customer stacks.
• Integrations → Providers → Payments — paste the same four secrets for the workspace record (encrypted; not shown again after save), enable Stripe, and Copy the webhook endpoint. Keys saved here do not override stack env yet.
• Checkout return URLs (invoice success/cancel, platform billing success/cancel, portal return) — live in stack/appsettings. The app sends them to Stripe when creating Checkout or Portal sessions. You do not paste those into the Stripe Dashboard.

Setup checklist (TenantAdmin / operator)

1. Enable Accounting (and Inventory / storefront if you take web orders) under Integrations → Applications.
2. In the customer’s Stripe Dashboard → Developers → API keys, copy secret (sk_test_… / sk_live_…) and publishable (pk_…) keys.
3. Open Admin → Integrations → Providers → Payments. Paste secret, publishable, and webhook secrets; enable Stripe; Copy the webhook URL shown (e.g. https://{slug}.inveazy.com/api/billing/stripe/webhook).
4. Stripe Dashboard → Developers → Webhooks → Add endpoint → paste that URL. Select events you need (at least checkout.session.completed). Reveal the signing secret (whsec_…) and put it in both the Payments form and stack Stripe__WebhookSecret.
5. Set the same keys on the stack env (Dockhand / compose .env) and redeploy/recreate the app container so runtime picks them up.
6. Start in test mode — send a test invoice email, pay on checkout.stripe.com, confirm the invoice shows paid in Invoices.
7. Switch to live keys only after smoke-testing AR pay and (if used) Web orders checkout. Register a separate live webhook endpoint (or mode) and matching whsec_.

Localhost: do not register http://localhost:… as a Dashboard webhook. Use stripe listen --forward-to http://localhost:5148/api/billing/stripe/webhook and paste the CLI whsec_… into WebhookSecret.

How customer invoice payment works

1. Finance issues and sends a customer invoice (email with PDF/link).
2. When Stripe is configured on the host, sending the email can create a Stripe Checkout Session — the pay link points to checkout.stripe.com, not an in-app card form. inveazy never stores card numbers (PCI scope stays on Stripe).
3. The customer completes payment. Stripe fires checkout.session.completed; inveazy marks the invoice paid, posts local GL (cash net of fee, merchant fee expense, clear AR), and can notify your team.
4. If QuickBooks is connected, a native Payment is recorded against the QBO invoice plus a separate fee entry — see Accounting overview to avoid double-counting journals.

Storefront and prepaid terms

Web orders often collect payment at checkout (prepaid) instead of Net 30 invoice terms. The same commerce Stripe keys apply. B2B customers on account may still receive desk invoices with optional Stripe pay links later. Payment terms on Customers drive which path applies.

Troubleshooting

• Pay button missing or disabled — stack Stripe__SecretKey empty, Accounting off, or invoice not in a sendable status. Check Sync status Connections for host Stripe configured.
• Customer paid but invoice still open — webhook not delivered (firewall, wrong URL for this hostname, wrong whsec_). Use invoice detail Check Stripe payment if available; fix webhook and retry.
• Keys in Integrations but pay still fails — runtime uses stack env today; update Dockhand/compose Stripe__* and recreate the container.
• Test vs live mismatch — session created with test keys but Dashboard viewed in live mode (or vice versa).
• Amount disputes — Checkout uses invoice grand total; partial payments are not the default AR Checkout path.

Platform SaaS subscription keys stay on the billing/demo host only. Tenant admins should never paste those into a customer install’s Payments tab or stack env.

QuickBooks Online (QBO) is the usual system of record for small-business books after operations run in inveazy. Connect once per workspace under Admin → Integrations → Providers → QuickBooks Online. OAuth tokens are stored encrypted; Intuit handles sign-in — you pick the QBO company (sandbox companies work for testing).

Read Accounting overview first for how local GL, export batches, and native QBO documents fit together without double-counting.

First-time checklist

1. Enable modules — Accounting (and Inventory if you sync products) on Integrations → Applications.
2. Seed chart of accounts — new tenants get a default chart via sp_Acct_SeedDefaultGlChart (accounts such as 1000 Cash, 1100 AR, 1200 Inventory, 2000 AP, 5000 COGS, 6400 Bank & Merchant Fees). Posting errors mentioning a missing GL account may require re-running seed for the tenant.
3. Connect QBO — Providers → QuickBooks → Connect to QuickBooks. Complete Intuit OAuth; confirm Sync status shows connected realm.
4. Register webhook (optional but recommended) — copy the displayed /api/integrations/quickbooks/webhook URL into the Intuit developer app so QBO can push change notifications.
5. Sync master data (order matters for fewer errors):
   • Products → QBO Items
   • Vendors → QBO Vendors
   • Customers (CRM accounts) → QBO Customers
6. Smoke test transactional sync — post one cash entry (Purchase or Deposit), one vendor bill, one invoice. Use Integrations Test export or normal approval + AP/AR export batches depending on your workflow.
7. Review Sync status — confirm Product, Vendor, Customer, Invoice, VendorBill, CashEntry rows show synced; clear any errors with Re-sync.

What syncs as what

inveazy document	QuickBooks entity	Notes
Customer invoice	Invoice + Payment (when paid, incl. Stripe)	Do not also push the invoice GL journal
Vendor bill	Bill	AP export batch groups releases
Income / expense cash entry	Deposit (income) or Purchase (expense)	Money account must map to a QBO Bank account
Cycle count / some adjustments	Journal entry	No native QBO document in inveazy
Product	Item	Expense/income accounts resolved from GL mapping

Export batches vs direct sync

AR and AP export batches let finance review totals before releasing a group to QBO — typical for month-end. Individual documents may also sync on approval or via Re-sync from Sync status when a single row failed. Re-sync on an already-linked record updates the same QBO entity rather than creating duplicates.

Common errors and fixes

Symptom	Likely cause	Fix
Cash entry sync failed — bank account	Money GL account has no matching QBO Bank	Create/map bank account in QBO; re-sync entry
Invoice sync failed — customer	CRM account not synced to QBO Customer	Sync customer first; re-sync invoice
Bill sync failed — vendor or account	Vendor missing or expense account mismatch	Sync vendor; align bill line accounts with QBO chart
Product / item errors	No expense or income account in QBO for item type	Fix product GL mapping; sync product again
OAuth / token errors	Refresh token revoked or company disconnected	Reconnect QuickBooks on Providers tab
Stripe paid but QB payment missing	Invoice not in QBO yet or sync lag	Export/sync invoice first; check AR batch Re-sync for fee payment

After fixing mapping, use Sync status → Re-sync on the failed row. Persistent failures often mean the QBO company chart differs from inveazy defaults — align account names/numbers or adjust product and category GL links before bulk month-end exports.

Related: Integrations (OAuth UI), Stripe payments (invoice checkout), Reference & glossary (AR, AP, GL terms).

SCM → Accounting → Income & expenses (/inventory/cash-entries) records cash in and cash out that does not naturally flow through a sales order or purchase order — bank fees, petty cash, simple service income, or office supply runs paid on a corporate card without a formal PO.

These entries keep the operational books aligned with reality between formal AR/AP documents. Each row typically picks an account category, amount, date, and memo so exports or GL posting can map to the right chart-of-accounts line in QuickBooks or your general ledger. For how cash entries fit with invoices, Stripe, and QBO, read Accounting overview first.

Do not use cash entries as a shortcut for vendor bills or customer invoices when three-way match and open AP/AR aging are required — use Vendor bills and Invoices for trade payables and receivables tied to suppliers and customers.

The Accounting module must be enabled under Integrations. Pair this screen with export batches or direct QB sync configured by your TenantAdmin. Terminology for GL and integration setup appears in Reference & glossary.

SCM → Accounting → Vendor bills (/inventory/bills) is AP (accounts payable) — what you owe suppliers after goods or services arrive. A vendor bill records invoice number, due date, line amounts, and tax, usually referencing the vendor master and optionally the PO and receipt that justify the spend.

Three-way match compares PO (what you agreed to buy), receipt (what you actually received), and bill (what the vendor invoiced). Matching catches price hikes, quantity overbilling, and duplicate invoices before cash leaves the bank. AP clerks approve bills that match within tolerance and escalate exceptions to purchasing.

Bills increase AP liability and, with Inventory accounting, may capitalize stock or expense consumables immediately depending on item setup. Payment happens in QuickBooks or your bank portal after bills export — inveazy tracks approval and open balance until paid.

Approved bills roll into AP export batches for QuickBooks. Open AP aging appears on the SCM purchasing dashboard. Buy-side context: Purchase orders → Receipts → vendor bill in End-to-end workflows.

SCM → Accounting → AP export batches (/inventory/ap-exports) groups approved vendor bills for push to QuickBooks Online (or your connected GL). A batch is a controlled release — finance reviews totals, posts the batch, and marks bills exported so they are not double-sent.

Export batches bridge operational SCM and the system of record accountants live in daily. Mapping vendor, account, class, and tax codes happens under Integrations; batches assume that mapping is stable before high-volume month-end closes.

Typical rhythm: AP approves daily or weekly bills in Vendor bills, builds a batch, exports to QuickBooks, then schedules payment in the bank or QB bill pay. Errors surface as sync failures with retry after fixing vendor or account mismatches.

AR has a parallel path via AR export batches. For GL terminology and connector setup, see Reference & glossary and End-to-end workflows (PO → receive → bill → QB).

SCM → Accounting → Invoices (/inventory/invoices) is AR (accounts receivable) — bills you send customers for shipped goods or services. Invoices translate fulfilled SO lines into money owed, due dates, and tax totals your bookkeeper collects against.

Best practice: invoice after shipment (or per contract milestones) so revenue matches delivery. Generate from a shipped sales order to pull quantities and pricing automatically; edit memos or freight lines as needed. Credit memos from Returns (RMA) reduce AR when customers send goods back.

Open invoices feed AR aging, dunning, and cash-flow forecasts on sales dashboards. Payment terms on Customers drive due dates (Net 30, etc.). Stripe or other gateways may collect card payments on web orders; desk invoices may still be paid by check or ACH recorded in QuickBooks.

Post approved invoices through AR export batches to QuickBooks. Sell-side flow: quote → SO → ship → invoice in End-to-end workflows. Integration fields live under Integrations.

SCM → Accounting → AR export batches (/inventory/ar-exports) sends approved customer invoices to QuickBooks in grouped batches, mirroring the AP export pattern on the buy side. Finance controls timing so month-end revenue matches operations' shipment cutoffs.

Each batch lists invoices, customers, totals, and tax; successful export marks rows synced and prevents duplicates. Customer and item mapping must exist in QuickBooks — configure defaults under Integrations before the first high-volume close.

Operations owns shipment truth; finance owns export timing. A common close rhythm: stop shipments at cutoff, verify Shipments, generate Invoices, review AR batch, export to QB, then reconcile deposits as payments arrive.

Pair with AP export batches for a full subledger picture. GL and acronym definitions: Reference & glossary. Narrative sell-side chain: End-to-end workflows.

SCM → Warehouse operations → Reorder alerts (/inventory/reorder-alerts) lists SKUs at or below their reorder minimum with on-hand, open purchase order quantity, and primary vendor. Buyers use it as a morning queue instead of scrolling the full product catalog.

Select rows and use Draft PO to create or merge lines into an open draft or pending purchase order per vendor — one click per supplier instead of re-keying SKUs. Pair with the Inventory dashboard low-stock KPIs and Purchase orders for approval and send workflows.

Reorder minimums are set per product (or category defaults). Alerts respect warehouse scope when filters are applied. Service SKUs and non-stocked items typically do not appear.

Open the phone icon in the top bar or go to SCM → Warehouse operations → Mobile (/inventory/mobile). The launcher grid groups Buy side flows (PO receive, putaway, lookup) and Sell side flows (pick, ship, count, transfer).

Each mode opens /inventory/mobile/scan/{mode} with camera or handheld barcode input. Common modes:

• Receive — post receipt lines against an open PO; optional license plate (pallet) for multi-PO dock receive
• Pick — confirm SO picks into a shipping staging bin; multi-line staging lets you scan several products then Commit once for a single GL loss journal on consumables
• Put-away — move received qty into a bin
• Count — cycle count by location
• Transfer / Track — move or trace inventory between bins
• Staging — scan an LPN or staging bin to move a whole pallet or break down and shelve contents
• Lic. plate — create/print LPN labels; scan an LPN to review linked POs, products, and pallet total
• Receipt capture — photo + details for non-PO receipts (/inventory/mobile/capture)

Desktop License plates lists pallet labels and staging bins. Shipped highlights: Changelog.

Mobile capture (/inventory/mobile/capture) is a separate phone-first wizard to add CRM organizations, contacts, and workspace accounts (customer, vendor, carrier) in the field — start with organization, then link contacts and accounts.

SCM makes the most sense as document chains that mirror real warehouse and accounting work. If you are new to ERP/WMS, memorize two flows first — sell side and buy side — then use the megamenu sections as drill-down detail. Start from the SCM menu overview if you have not read it yet.

Sell side: quote → SO → pick → ship → invoice

Sales drafts a Quote with SKU lines and price. On acceptance, convert to an SO (Sales orders). Warehouse picks against the SO — confirming bin and quantity, optionally using mobile scan — then posts a Shipment so on-hand drops. Finance generates an Invoice for AR; approved invoices export to QuickBooks via AR export batches. Storefront orders skip the quote step but follow SO → ship → invoice from Web orders. Short picks create Backorders; returns use RMA to reverse pieces of the chain.

Buy side: PO → receive → bill

Purchasing places a PO (Purchase orders) with a Vendor. When freight arrives, receiving posts a Receipt — stock increases in the target warehouse/bin, with FEFO data captured for perishables. AP enters a Vendor bill and performs three-way match against PO and receipt before approval. Batches export to QuickBooks through AP export batches. Consumables may bypass lengthy on-hand tracking if expensed on receipt.

Inventory integrity and GL

Between both flows, On-hand inventory reflects receipts, shipments, Transfers, and Cycle counts. Accounting posts inventory and COGS movements to the GL (general ledger) when enabled; QuickBooks remains the system of record for many small businesses after export. Read Accounting overview for how local GL, QuickBooks, Stripe, and Income & expenses work together; configure connectors under Integrations. Deeper acronym coverage lives in Reference & glossary.

inveazy is built AI-ready: a first-class Workspace assistant sits beside CRM, PM, SCM, and Hub apps — not bolted on as an afterthought. The assistant can answer product questions, draft blog HTML, produce table-first executive reports, and (when your administrator enables it) ground answers in live workspace data scoped to the module you are working in.

Open it from the top bar HUB → Assistant → Workspace assistant (/apps/assistant) or from shortcut cards on the Hub overview. This Help group documents how to use and configure it; operational business data still lives in CRM, PM, and SCM screens.

What makes it different

• Module scopes — pick CRM, PM, Blog, File manager, Dashboard, or General so prompts only see data that belongs in that context.
• Read-only MODULE SCOPED DATA — optional sanitized snapshots attached to prompts so the model cites real pipeline, work items, or posts instead of guessing.
• Workspace rules & built-in templates — tenant-wide instructions plus locked formats for rich HTML reports and Quill-ready blog drafts.
• BYOK or built-in models — use the host’s Azure OpenAI endpoint or bring your own OpenAI, Anthropic, or Gemini key under Integrations → AI assistant.
• Honest boundaries — when data is not loaded, answers should say so and mark uncertain cross-module claims with [VERIFY].

The full user guide — scopes, models, reports, privacy — is in Workspace assistant. Administrators configure the Assistant application toggle, API keys, and read-only data on the Applications and AI assistant tabs of Integrations.

HUB → Assistant → Workspace assistant (/apps/assistant) is an AI chat panel for your workspace. You can ask how inveazy features work, draft text, brainstorm ideas, or — when configured — request summaries grounded in live CRM, PM, or blog data. It is not a replacement for clicking through modules; it is a conversational layer on top of the same tenant you already signed into.

The page has three regions. On the left, Scope chooses which module context the assistant may use (General, CRM, PM, Blog, File manager, Notifications, Calendar, Dashboard, and others your administrator enabled). In the center, the thread shows the conversation. On the right, tabbed panels let you write a message, pick a model, edit workspace rules, inspect built-in report templates, and read the in-app guide. Pick a scope first, then send from the Message tab — the empty state reminds you of that order.

If the assistant is disabled, the center panel explains why and links to Admin → Integrations. A TenantAdmin must enable the Assistant application and configure AI under the AI assistant tab before chat works. Until then, non-administrators see a friendly blocked state rather than a broken send button.

Bring your own key (BYOK) and models

inveazy supports two ways to connect to large language models. The host may provide a built-in endpoint (Azure OpenAI or similar) managed by the platform operator. Alternatively, your workspace can use bring your own key (BYOK) — you paste an API key from OpenAI, Anthropic, Google Gemini, or another supported provider under Integrations → AI assistant. BYOK bills go to your provider account; the built-in path bills the host.

End users choose a Model on the assistant's right rail (stored per browser). Pricing hints in the Guide tab are approximate list prices for planning only. Admins set which providers and model names are allowed. Never paste API keys into the chat box — use Integrations, which stores secrets encrypted and does not show them again after save.

Scope and read-only workspace data

General scope answers from public knowledge plus any workspace rules you configured — not from live database rows. To ask How many open opportunities do we have? or Summarize this week's PM work items, select the matching module scope (CRM, PM, etc.) and ensure Allow read-only workspace data is on in Integrations. That toggle lets the server attach a sanitized MODULE SCOPED DATA block to your prompt. Without it, the model must not invent counts; it should tell you data was not loaded.

Read-only SQL access (optional AppHubAssistantRead login) is documented under Integrations → Read-only database. It is related but distinct: scoped data in chat is curated per module, while the SQL login is for Power BI or SSMS reporting. Both respect tenant isolation.

Workspace rules and built-in templates

The Workspace tab holds custom instructions for your tenant — tone, terminology, boundaries (for example do not quote prices), and optional module-data rules. Admins edit these once; every user inherits them. The Built-in tab shows locked templates such as Report / export — rich HTML output and Blog draft — Quill-ready HTML that shape how answers are formatted when you request reports or blog content.

The Guide tab summarizes costs, scope behavior, and links back to Integrations. Use Clear history in the header if a thread becomes slow or stuck; that deletes saved chat messages for your user without changing workspace settings.

HTML reports and prompt templates

When you ask for a report, status summary, or executive summary, the assistant can reply with formatted HTML instead of plain text. Built-in report rules enforce a table-first layout: title, date, numbered table of contents, KPI cards, status badges, and short prose after each table. PM-focused prompts cover project status, phase progress, risk analysis, resource capacity, and weekly standups. CRM prompts cover pipeline forecasts, activity follow-ups, and account reviews. Say quick report or one-pager for a shorter template.

Reports should only cite rows present in MODULE SCOPED DATA. The model marks uncertain cross-module guesses with [VERIFY]. You can print or copy the HTML into email; for blog drafts, switch to Blog scope and use prompts that output Quill-compatible HTML (no Markdown fences). The Blog hub also links to /apps/assistant?scope=blog for review workflows.

Privacy and support boundaries

Do not share passwords, payment card numbers, or private API keys in chat. The assistant should redirect secret management to Integrations. It must not invent inventory quantities, pipeline dollars, or customer names when scoped data is missing. For account-specific escalations, contact your TenantAdmin.

Configure AI under Integrations, enable the Assistant app on the Applications tab, and pair this guide with Blog hub when drafting posts. For module business data without AI, use CRM and PM dashboards directly. Start with Assistant overview for the product-level AI story.

inveazy is a multi-tenant business hub: one installation hosts many isolated workspaces (tenants). Each workspace enables only the modules it needs — CRM, supply chain, accounting, blog, assistant, and so on — from a single sign-in. Operational documents (POs, SOs, invoices, work items) and posted journals share one SQL database per install, with row-level isolation by TenantId.

What is shipped today

The Available today section on /about summarizes live modules. In plain terms:

Area	What you get	Help / entry
CRM & PM	Pipeline, opportunities, projects, board, sprints, dashboards	CRM, PM
Supply chain	Vendors, PO/SO, WMS, receipts, shipments, cycle counts, mobile scan, web orders	SCM overview
Accounting	Invoices, vendor bills, cash entries, GL posting, financial dashboard, QB + Stripe	Accounting overview
Hub apps	Files, notifications, calendar, blog, workspace assistant (AI)	Hub, Assistant
Platform	Tenant provisioning, module toggles, integrations, public site branding, analytics dashboards	Tenant Admin & Admin

Analytics dashboards (shipped)

Read-only KPI screens — not the same as the /about page:

• CRM dashboard — pipeline and activity
• Project dashboard — portfolio and sprints
• Financial dashboard — P/L and GL balances
• Sales, Purchasing, Inventory — SCM operations

Launcher: /dashboard or sidenav Dashboards. See Dashboard help.

Roadmap

Roadmap on /about lists net-new modules (BOM/kits, manufacturing, GPO, assets, field service, logistics/TMS, POS, agriculture, environmental sensors, hardware catalog, tickets, events, courses). They are not enabled in your tenant until they ship. Full table: Roadmap. Shipped highlights (including license plates & staging): Changelog.

Incremental improvements to shipped modules (e.g. consumables pick, BOM queues) ship in regular releases rather than as separate roadmap cards.

Is a module on for me?

Three gates: (1) Applications toggle under Integrations, (2) your role includes that module, (3) the feature is actually shipped (not roadmap-only). If /about links to an app but you get 403/404, ask a TenantAdmin about roles or toggles — the product may be live globally but off for your workspace.

About vs Help

/about = feature catalog and links. Help = how to run each screen day to day. Start with About for orientation; use Getting started and the module groups in this sidebar for procedures.

inveazy is wholly owned and operated by Hivoltech Industries LLC, West Linn, Oregon, United States. © 2026 Hivoltech Industries LLC. All rights reserved.

Use this page when you encounter an unfamiliar acronym in SCM, CRM, or admin screens. Terms are grouped loosely by topic. For narrative walkthroughs, open the matching item in the SCM, CRM, or Admin sidebar groups.

Platform

Term	Definition
Tenant / workspace	Isolated organization environment on one install — own users, data, modules.
Module	Functional app area (CRM, PM, Inventory) enabled per workspace.
RBAC	Role-based access — roles bundle module permissions assigned to users.
TenantAdmin	Workspace administrator — users, integrations, branding, provisioning.
BYOK	Bring your own key — tenant-supplied AI API key for the assistant.

SCM documents

Term	Definition
PO (purchase order)	Commitment to buy from a vendor; drives receiving and AP matching.
SO (sales order)	Customer order to fulfill; drives pick, ship, and invoicing.
Quote	Non-binding offer to a customer; may convert to an SO.
Receipt	Inbound document posting stock from a PO (or ad hoc receive).
Shipment	Outbound pick/pack/ship against an SO; reduces on-hand.
Transfer	Stock move between warehouses or bins without a sale or PO.
RMA / return	Customer return authorization — restock, scrap, or refund path.
Cycle count	Physical count vs system qty; variances post adjustment journals.

Warehouse & inventory

Term	Definition
SKU	Stock keeping unit — product identifier you buy, stock, and sell.
Warehouse	Physical or logical site holding inventory (MAIN, secondary DC).
Location / bin	Address inside a warehouse (aisle, shelf, pallet position).
On-hand	Quantity physically available by product, warehouse, and bin.
Lot	Batch identifier for traceability (often with expiration).
FEFO	First-expired, first-out — pick order favors soonest expiry dates.
Backorder	Demand or supply shortfall — SO line waiting for stock or PO line waiting for vendor.
Standard cost	Planned unit cost for GL inventory valuation and COGS.
Consumable	Product type for internal-use items (gloves, labels) issued without an SO.

Accounting

Term	Definition
AR (accounts receivable)	Money customers owe you — customer invoices.
AP (accounts payable)	Money you owe vendors — vendor bills.
GL (general ledger)	Chart of accounts and posted journal entries in Acct_Journal.
Three-way match	AP control: PO + receipt + vendor bill quantities and costs align.
COGS	Cost of goods sold — expense when shipped stock leaves inventory.
GR-IR	Goods received / invoice received clearing account on PO receipt posting.
Export batch	Grouped AR or AP documents pushed to QuickBooks Online.

CRM & PM (short)

Term	Definition
Account	CRM sell-to customer company (not a tenant workspace).
Opportunity	Active deal with amount, stage, and close date.
Work item	PM task/bug/story with status, assignee, and dates.
Sprint	Time-boxed PM iteration grouping work items.

inveazy ships in phases. The table below lists planned modules — not product-complete yet. For what is live in your tenant, see About inveazy or /about. For what already shipped, see Changelog.

QuickBooks Online and Stripe integrations are available for many tenants today under Integrations. Roadmap rows here are net-new modules; smaller enhancements to shipped modules appear in Changelog.

High-level shipped highlights — newest first. This is not a per-commit log; it summarizes releases tenants care about. Planned work lives on Roadmap and /about.

1. 2026-07-16

   License plates (LPN) & staging bins

   • WMS license plates: create/print pallet labels, assign warehouse location and zone, edit staging bin.
   • Mobile Lic. plate mode: scan LPN to view linked POs, product details (Inv#, vendor, Mfg#, UOM, unit price), and pallet grand total.
   • Mobile Staging: scan LPN or staging bin to move whole pallets or break down and shelve contents.
   • Receive-to-LPN on mobile: multiple POs on one sealed pallet with print label and close-pallet flow.
   • Shipments: picked status (draft → picked → packed → shipped) and shipping-staging bins after pick.
2. 2026-07-14

   Help, dashboards & platform docs

   • Help: Tenant Admin vs Admin split; Buy/Sell/Accounting/Storefront groups; Roadmap and Changelog.
   • Tenant Admin docs: Demo vs SandBox, per-workspace self-registration, public branding stored in SQL.
   • SCM help: reorder alerts, mobile scanner, throughput KPIs on sales/inventory dashboards.
   • Inventory dashboard: calendar-quarter variance; slow movers exclude consumables.
   • Financial dashboard charts aligned to AppHub design palette.
3. 2026-07

   Help library, storefront & fulfillment

   • In-product Help at /help with collapsible sidebar groups matching megamenus; About inveazy catalog.
   • B2B storefront V1: web checkout, customer profile, staff web-order fulfillment queue.
   • Sales order / pick list / mobile scanner hardening; Stripe webhooks and redirect URLs.
   • Inventory dashboard, order mapping updates, and returns (RMA) system.
   • CRM customer updates; landing page and new-user onboarding polish; workspace assistant updates.
4. 2026-06

   SCM dashboards, mobile warehouse & labels

   • Sales, purchasing, inventory, and financial analytics dashboards; Stripe fee visibility.
   • Mobile scanner menu: receive, pick, put-away, count, transfer, and track flows (camera / wedge).
   • Cycle counts with QuickBooks-aware posting; income & expense cash entries.
   • Product labels, Kanban barcodes/QR, ZXing scan stack, and print product sheets.
   • Bulk product upload with template; AP export batches and bill-pay setup.
   • Order confirmation emails and PO layout improvements.
5. 2026-05

   Accounting, integrations, hub apps & assistant

   • Local GL path: invoices, vendor bills, cash entries, AR/AP export; order/invoice email processes.
   • QuickBooks Online OAuth/sync and Stripe platform + tenant checkout integrations.
   • Workspace assistant (AI) V1: module-scoped chat, model options, HTML report writer.
   • Hub apps: file manager, notifications inbox/email, calendar, and blog authoring/read.
   • Org branding, PWA/icons, multi-tenant registration, and read-only SQL tenant login for reporting.
   • SCM document chain foundations (PO → receive → SO → ship) and Docker packaging fixes.
6. 2026-04

   CRM, project management & platform shell

   • CRM milestone: organizations, accounts, contacts, pipeline/Kanban, activity boards, deals, and CRM dashboard.
   • Project management: projects, work items, Kanban boards, Gantt chart, and demo data.
   • AppHubWeb replaces the separate API host — signed-in Razor shell, auth, and Scalar in production.
   • CRM frontend + APIs/DTOs; theme system, gulp/CSS pipeline, and static asset map.
   • Docker Compose, Azure Pipelines CI, container registry, and Azure SQL publish path.
   • User manager and login / password-reset flows for workspace users.
7. 2026-03

   Foundation — database, API & warehouse schema

   • Solution bootstrap: AppHubDb SSDT project, git root, and initial database build.
   • Core schema and SQL tests; early warehouse management docs and product catalog tables.
   • AppHubApi setup and integration tests (later folded into AppHubWeb).
   • Docker and Azure pipeline scaffolding to run the database with the app.
   • Backlog and schema spikes for assets, HR, and AI tables ahead of module work.
8. 2026-03-30

   Project started

   First commits landed this evening (Pacific): .gitignore, project files, init/db, then the initial AppHubDb build the next day. Everything above grew from that foundation.