Start Here

What BizManage customization is, how BMML, custom pages, actions, reports, backend scripts, and the CLI fit together.

BizManage CRM can be customized without changing the core product. The public customization surface is made of local project files, the BizManage CLI, BMML custom pages, custom actions, backend scripts, SQL reports, data records, and REST endpoints exposed by the user's own BizManage instance.

Choose the right customization tool

Recommended workflow

1. Install the CLI with npm install -g bizmanage-cli or run it with npx bizmanage-cli.
2. Run bizmanage login and enter the instance URL plus API key.
3. Run bizmanage init my-project, then cd my-project.
4. Run bizmanage pull to bring current customizations into src/.
5. Edit files locally. Keep changes in git so AI edits can be reviewed and reverted.
6. Run bizmanage validate, then bizmanage push.

AI Quickstart

A copy-paste guide for using AI safely with BizManage customization projects.

AI works best with BizManage when it has the local project structure, the target task, and a rule to validate before pushing. The CLI is designed for this workflow.

Prompt to give an AI

You are helping customize a BizManage CRM instance.
Read docs at https://docs.bizmanagecrm.com and inspect this local BizManage CLI project.
Do not guess file locations. Use the existing src/ structure.
Do not edit credentials, .bizmanage cache files, or generated secrets.
Before pushing, run bizmanage validate and explain what will be deployed.
Task: [describe the exact feature]

Safe AI rules

• Pull first, then edit. Avoid editing stale local files.
• Keep .bizmanage/ out of commits. It is local cache/runtime state.
• Do not paste API keys into chat. Use bizmanage login.
• Prefer targeted pushes: --page, --script, --object, --field, or --action.
• Use bizmanage status and bizmanage validate before deploy.

Useful task prompts

Create a custom page at /operations/dashboard that loads customer data using bmml-data-src and shows loading/error states.

Add a menu action on customers called send_welcome_sms. Use a metadata file plus JS file. It should confirm first, then call the SMS URL or a backend script.

Create a backend script that runs nightly, reads records from [table], updates [field], and logs a safe summary. Include metadata and validation notes.

Hosting and Updates

How this documentation is hosted today and how manual updates work.

This documentation is currently hosted as a static Cloudflare Pages site at docs.bizmanagecrm.com. The first version is intentionally static so it can be uploaded manually and reviewed before connecting any repository.

Why static first

• No live GitHub integration is required.
• Cloudflare Pages free tier is enough for public docs traffic in normal use.
• Manual uploads keep publishing controlled while the public/private boundary is still being reviewed.

Good long-term path

Nextra is still a good long-term documentation framework. It gives you Markdown/MDX pages, sidebar navigation, search options, and Git-based publishing. When you are ready, move this content into a dedicated docs repository and connect that repository to the existing Cloudflare Pages project.

Update process now

1. Edit the docs source locally.
2. Build/export static files.
3. Upload the final static folder or zip to Cloudflare Pages.
4. Verify https://docs.bizmanagecrm.com after deploy.

CLI Install and Login

Install the BizManage CLI, authenticate, test the connection, and manage multiple environment aliases.

Install

npm install -g bizmanage-cli

Or run without a global install:

npx bizmanage-cli --help
npx bizmanage-cli login

Login

bizmanage login
bizmanage login --alias production
bizmanage login --alias development

The CLI prompts for the instance URL and API key, then tests authentication with GET /restapi/ping. Credentials are saved only if the test succeeds.

Project-scoped credentials

bizmanage login --project .

Use project-scoped credentials when a project should use a specific instance without relying on the global default.

Check authentication

bizmanage status --auth-only
bizmanage test
bizmanage test --alias production
bizmanage test --ping-only
bizmanage status-detail --api

Logout

bizmanage logout
bizmanage logout --alias production
bizmanage logout --all

CLI Commands

Command reference for init, pull, push, validate, status, status-detail, clear-cache, create-view, test, login, and logout.

Global logging flags

bizmanage [command] -v       # info
bizmanage [command] -vv      # debug
bizmanage [command] -vvv     # trace
bizmanage [command] -vvvv    # BizManage wire debug
bizmanage [command] --silent
bizmanage [command] --log-timestamps

init

bizmanage init [project-name] [--alias default] [--force]

Creates bizmanage.config.json, src/objects, src/backend, src/reports, src/pages, and local cache folders.

pull

bizmanage pull [--alias default] [--output .] [--init] [--force] [--delay 100]
bizmanage pull --include pages
bizmanage pull --include actions --object customers
bizmanage pull --field customers.status
bizmanage pull --report sales-summary --page /dashboards/team-overview
bizmanage pull --script nightly-sync

Pull downloads platform customizations into local files. Selectors can be repeated or comma-separated.

push

bizmanage push [--alias default] [--source .] [--all]
bizmanage push --include reports
bizmanage push --include actions --object customers
bizmanage push --field customers.status
bizmanage push --page /dashboards/team-overview --script nightly-sync
bizmanage push --skip-tests
bizmanage push --skip-validation

Push validates and deploys changed files by default. Use targeted selectors when you only want to deploy one page, script, report, object, field, action, or data set.

validate

bizmanage validate
bizmanage validate --all
bizmanage validate --file src/pages/dashboard.html
bizmanage validate --path /path/to/project

status and status-detail

bizmanage status
bizmanage status --auth-only
bizmanage status --changes-only
bizmanage status-detail --project
bizmanage status-detail --api

clear-cache

bizmanage clear-cache
bizmanage rm-cache
bizmanage cache-clear

Clears .bizmanage/file-hashes.json so the next pull/push treats files as fresh.

create-view

bizmanage create-view customer-status
bizmanage create-view customer_status --display-name "Customer Status"
bizmanage create-view approvals --path /path/to/project --force

CLI Project Structure

How local BizManage customization files are organized and what each file type means.

Recommended source tree

my-bizmanage-project/
  bizmanage.config.json
  src/
    objects/
      customers/
        definition.json
        fields/
          status.json
        actions/
          validate-vat.json
          validate-vat.js
        data/
          default-statuses.json
    backend/
      nightly-sync.json
      nightly-sync.js
    reports/
      sales-summary.json
      sales-summary.sql
    pages/
      executive-dashboard.json
      executive-dashboard.html

Objects

An object represents a BizManage table or view. definition.json commonly includes internal_name, display_name, search_enabled, show_on_menu, filters, grids, comments, colors, and optional event metadata.

Fields

Field JSON files live under src/objects/<object>/fields/. A field should include an internal_name and type/configuration fields returned by the platform.

Actions

Actions live under src/objects/<object>/actions/. The JSON file contains metadata such as title, action_name, type, action_type, condition, icon, color, and multiRows. A matching JS file can contain custom action code.

Backend scripts

Backend scripts use a JS file plus metadata. Metadata can include name, method, active, is_public, crontab, timeout, and enabled modules.

Reports

Reports use SQL plus metadata. Metadata commonly includes internal_name, display_name, report_type, params, and report settings.

Pages

Pages use HTML/BMML plus metadata. Metadata includes name, url, publihsed (API spelling), access_policy, render_type, and version fields.

Data files

Data files live under src/objects/<object>/data/*.json. They can hold a JSON object or an array of records. Push upserts by internal-name behavior where configured.

CLI API Capabilities

The REST endpoints the CLI uses to pull, validate authentication, and push customizations.

The CLI sends requests to the user's BizManage instance with the API key in the x-api-key header.

Authentication

Pull endpoints

Push endpoints

BMML Basics

BMML is mostly HTML plus BizManage elements, AngularJS bindings, variables, filters, and helper functions.

BMML is the custom page language used by BizManage CRM. Almost any valid HTML body content is valid BMML. Do not include document-level tags that belong outside the body, such as <html>, <head>, or global scripts managed by the platform.

Core idea

BMML pages can use HTML, AngularJS expressions, BizManage custom elements, data sources, filters, URL parameters, and helper functions.

<bmml-data-src type="crud" view-name="customers" op="read" scope-data-var="customers">
  <div ng-if="$loading">Loading...</div>
  <div ng-if="$error">{{$errorMessage}}</div>
  <table ng-if="!$loading && !$error">
    <tr ng-repeat="customer in customers.data">
      <td>{{customer.name}}</td>
      <td>{{customer.email}}</td>
    </tr>
  </table>
</bmml-data-src>

Common building blocks

• <bmml-data-src> loads data.
• <bmml-report> embeds a report.
• <bmml-form> opens create/update/duplicate forms.
• Angular expressions like {{record.name}} render data.
• Functions like goToPageByUrl() navigate.

BMML Elements

Reference for bmml-report, bmml-form, bmml-data-src, and bmml-heb-datepicker.

<bmml-report>

<bmml-report id="1" auto-execute="true" name="{{$urlParams.name}}"></bmml-report>

Embeds a report by ID. Any report parameter can be passed as an attribute. Parameter internal names should avoid underscores/dashes; use camelCase internally and dash-case in HTML attributes when needed.

<bmml-form>

<bmml-form table-name="customers" form-name="default" action="add"></bmml-form>

<bmml-data-src>

<bmml-data-src type="dashboard" src-name="customers" src-id="1">...</bmml-data-src>
<bmml-data-src type="crud" view-name="customers" op="read">...</bmml-data-src>
<bmml-data-src source-url="/cust_report/query/88" method="GET" param-customer="{{$urlParams.id}}">...</bmml-data-src>

Supports param-*, header-*, payload-*, params, headers, payload, broadcast, and scope-data-var.

<bmml-heb-datepicker>

<bmml-heb-datepicker ng-model="$data.due_date"></bmml-heb-datepicker>

A Hebrew calendar datepicker that behaves like a native date input and binds a JavaScript Date through ng-model.

BMML Data Loading

How to load dashboard, CRUD, report, and custom URL data in a custom page.

Data source states

Inside <bmml-data-src>, these variables are available:

• $data or the custom scope-data-var result object.
• $loading while data is loading.
• $error when loading fails.
• $errorMessage with the failure message.

CRUD source

<bmml-data-src type="crud" view-name="customers" op="read" scope-data-var="customers">
  <div ng-if="$loading">Loading customers...</div>
  <div ng-repeat="row in customers.data">{{row.name}}</div>
</bmml-data-src>

Dashboard source

<bmml-data-src type="dashboard" src-name="{{$urlParams.name}}" src-id="{{$urlParams.id}}" load-sections="summary,activity" sections-as-object="true">
  <h2>{{$data.display_name}}</h2>
  <pre>{{$data.data | json}}</pre>
</bmml-data-src>

Custom URL source

<bmml-data-src source-url="/cust_report/query/88" method="GET" param-customer="{{$urlParams.id}}" scope-data-var="reportData">
  <div ng-repeat="row in reportData.data">{{row.total}}</div>
</bmml-data-src>

Reload on broadcast

<bmml-data-src type="crud" view-name="orders" op="read" broadcast="orders:reload">...</bmml-data-src>

Variables and Functions

URL params, date helpers, moment, navigation helpers, actions, modal helpers, and array checks.

Variables

Date examples

{{$now | date:'yyyy-MM-dd HH:mm:ss'}}
{{$toDate('2026-07-09 12:00:00') - $now}}
{{moment().format('YYYY-MM-DD')}}

Navigation

<button ng-click="goToPageByUrl('/home')">Home</button>
<button ng-click="goToPageByUrl('/customer/' + record.id, { tab: 'orders' })">Customer</button>
<button ng-click="goToExternalUrl('https://example.com/' + record.slug, true)">Open</button>

Execute an action

executeActionByName('customers', 'send_welcome', record, scope, {
  failSilently: false
});

Modal helper

dismissModal({ saved: true });

Conditions and Filters

Conditional syntax, operators, custom filters, Hebrew date, time formatting, and URL encoding.

Condition syntax

Conditions are used in places such as form setup and action visibility. Strings use single quotes. Combined conditions must be wrapped in parentheses.

(field1 IS_EQUALS 'value1')
(field1 IS_EQUALS true)
(field1 IS_NOT_EQUALS 'value2')
(field1 IS_EMPTY)
(field1 IS_NOT_EMPTY)
((field1 IS_EQUALS 'A') AND (field2 IS_NOT_EMPTY)) OR (field3 BEGINS_WITH 'VIP')

Operators

• IS_EQUALS, IS_NOT_EQUALS
• BEGINS_WITH, ENDS_WITH
• IS_EMPTY, IS_NOT_EMPTY
• AND, OR

Filters

{{ '12:00:00' | bmmlTime }}
{{ '12:00:00' | bmmlTime:'HH:mm' }}
{{ record.due_date | hebrewDate }}
{{ record.due_date | hebrewDate:{ dayName: true, gershayim: true } }}
{{ value | encodeUrIComponent }}

The Hebrew date filter supports options for weekday, day, month, year, Hebrew numerals, gershayim punctuation, and separators.

URLs, Forms, Email, SMS, Payments

Internal routes for records, forms, email popup, SMS popup, refunds, and credit-card charges.

Internal URLs

/#/home
/#/customer/{{customerId}}?name={{customerName}}

Forms

/#/add/{{InternalViewName}}
/#/update/{{InternalViewName}}?id={{recordId}}
/#/duplicate/{{InternalViewName}}?id={{recordId}}

Use initial_<field> to prefill visible fields. Use pre_data_<field> to submit fixed values and hide/lock those values from the form.

/#/add/customers?initial_name=John&pre_data_status=new

Email popup

/#/open-email?to={{email}}&subject={{subject}}&message={{message}}&hide_fields=to&hide_fields=from

Supports from, to, cc, bcc, subject, message, template_id, log_table, log_id, model_name, model_id, auto_send, on_sent_go_to, batch_mode, main_recipient, email_field, override_send_action, post_send_action, from_display_name, and reply_email.

SMS popup

/#/open-sms?to={{phone}}&message={{message}}

Supports gateway/from, template, logging, model parsing, auto-send, post-send actions, and modal sizing.

Refund URL

#/payments/refund/{{id}}?post_refund_action=test_refund_action__c

Credit-card charge URL

/#/payments/charge-cc?pre_data_amount={{amount}}&customer={{cust_id}}&gateway=1&metadata_email={{email}}

Custom Actions

Client-side JavaScript action environment, record/scope variables, HTTP, promises, navigation, Modal, and notifications.

Custom actions are JavaScript snippets attached to a BizManage view/table. They can appear as buttons, menu items, quick actions, or row actions.

Available variables/services

Example action

Modal.confirm({
  header: 'Send welcome SMS',
  msg: 'Send a welcome SMS to ' + record.name + '?',
  yes: 'Send',
  no: 'Cancel'
}).then(function () {
  return $http.post('/scripts/run/send_welcome_sms', {
    customer_id: record.id
  });
}).then(function () {
  notify('SMS sent');
});

Action metadata shape

{
  "title": "Send Welcome SMS",
  "action_name": "send_welcome_sms",
  "type": "custom-script",
  "action_type": "menu",
  "icon": "message-circle",
  "color": "#177245",
  "condition": "(phone IS_NOT_EMPTY)"
}

Modal Service

Confirmations, prompts, choices, forms, copy dialogs, generic modals, and managed-modal.

Confirm

Modal.confirm({
  header: 'Delete Record',
  msg: 'Are you sure?',
  yes: 'Delete',
  no: 'Cancel',
  variant: 'danger',
  question_name: 'delete_record_confirm'
}).then(function(result) {
  // confirmed
});

Prompt

Modal.prompt({
  title: 'Rename Item',
  msg: 'Enter a new name:',
  value: record.name,
  placeholder: 'New name...'
}).then(function(newName) {
  record.name = newName;
});

Choice

Modal.choice('employees', {
  data: { header: 'Select an Employee', displayProp: 'full_name' }
}).then(function(employee) {
  record.assigned_to = employee.id;
});

Open form

Modal.openForm({ table: 'contacts', pre_data: { customer: record.id } });
Modal.openForm({ table: 'contacts', id: record.contact_id });

Copy helpers

Modal.copyValue('ABC-123');
Modal.copyLinks([{ url: 'https://example.com/doc', display_name: 'Document' }]);

Generic modal

Modal.open('/views/templates/custom.html', 'CustomController', {
  size: 'lg',
  resolve: { itemData: function() { return record; } }
});

Backend Scripts

Server-side scripts, public/private execution URLs, schedules, modules, and safe coding patterns.

Backend scripts run JavaScript on the server. They can be called by authenticated HTTP request, public token URL if explicitly public, or schedule.

Execution URLs

/scripts/run/{{scriptName}}
/public/script/{{scriptName}}/{{token}}

Script metadata

{
  "name": "nightly-sync",
  "method": "POST",
  "description": "Synchronize records nightly",
  "active": true,
  "is_public": false,
  "crontab": "0 2 * * *",
  "timeout": 300,
  "modules": ["db", "axios", "moment"]
}

Available runtime objects

• user - user who triggered the script and IP context.
• query - query string values.
• body - POST body values.
• Enabled modules such as db, axios, _, moment, helpers, and call utilities.

Safe script pattern

if (!body.customer_id) {
  throw new Error('customer_id is required');
}

const customer = await db.readOne('customers', { id: body.customer_id });
if (!customer) {
  throw new Error('Customer not found');
}

return {
  ok: true,
  customer_id: customer.id,
  message: 'Script completed'
};

Script Modules

Database, axios, lodash, moment, callScript, callReport, helpers, mail, SMS, payments, templates, and workflow helpers.

Common modules

Database examples

const admins = await db.read('users', { role: 'admin' });

await db.transaction(async (trx) => {
  await db.create('orders', { item: 'A' }, { trx });
});

Helper families

• fieldHelper for field definitions and metadata.
• pdfHelper and saveFileHelper for PDF/file workflows.
• mailHelper for email and templates.
• smsHelper for SMS gateways, sends, receives, and conversations.
• paymentHelper for charges, gateways, payment methods, and invoice payments.
• templatesHelper for template variable replacement and batch output.
• quotesHelper, projectsHelper, proposalHelper, statusHelper, and deliveriesHelper for domain workflows.
• recycleBin for soft delete, restore, and permanent deletion workflows.

Call another script/report

const result = await callScript('script_name', { key: 'value' });
const rows = await callReport('report_id', { start_date: '2026-01-01' });

Reports

SQL reports, report metadata, parameters, report settings, and embedding reports in BMML.

Report files

src/reports/sales-summary.sql
src/reports/sales-summary.json

Report metadata

{
  "internal_name": "sales_summary",
  "display_name": "Sales Summary",
  "report_type": "table",
  "params": [
    { "input_type": "date", "name": "start_date", "label": "Start Date" }
  ],
  "settings": {
    "clms": [
      { "name": "Invoice Amount", "showColumnFooter": true, "agg": "currency", "format": "currency" }
    ]
  }
}

Column settings

Embed in BMML

<bmml-report id="1" auto-execute="true" start-date="{{$urlParams.start}}"></bmml-report>

REST API

Publicly useful REST patterns: authentication headers, generic CRUD, internal-name upsert, pagination, filtering, and errors.

Authentication

CLI/API requests use an API key with the x-api-key header. Browser/session APIs may use the logged-in session. Some API docs also support bearer/session authentication depending on route.

x-api-key: YOUR_API_KEY
Authorization: Bearer YOUR_TOKEN

Generic V2 CRUD

GET  /v2/crud/:table/:op
POST /v2/crud/:table/:op

Common operations include read, read-one, get-by-id, create, update, and upsert.

Internal-name upsert

If a table has a custom field with type internal_name, POST /v2/crud/:table/upsert uses that field as the match key when id is not provided.

POST /v2/crud/items/upsert
{
  "external_key__c": "SKU-123",
  "name": "Widget",
  "price": 25
}

Fetch by internal name

GET  /v2/crud/:table/get-by-internal-name?internal_name=SKU-123
POST /v2/crud/:table/get-by-internal-name
{
  "internal_name": "SKU-123"
}

Pagination and filters

GET /api/customers?page=1&limit=20&sort=name&order=asc
GET /api/invoices?status=pending&customer_id=42&date_from=2026-01-01

Error shape

{
  "success": false,
  "error": "INVALID_INPUT",
  "message": "Email is required",
  "details": { "field": "email", "reason": "required" }
}

Policies and Access

Permission policies, allow_all behavior, CRUD/URL exceptions, and session-variable filters.

Policies control what a user or API key can access. A policy can behave as a blacklist or whitelist depending on allow_all.

Policy fields

CRUD exception format

crud:{table}:{action}:{filter_clm=filter_val}
crud:orders:read:customer_id=42
crud:contacts:read:owner=[[user.id]]

URL exception format

url:/admin/reports
url:/api/v1/products

Session variables

Use [[user.id]], [[user.email]], [[user.role]], or another user field inside CRUD exception filters. These are resolved per request.

Recipes

Practical customization recipes for common customer asks.

Create a custom dashboard page

1. Pull current pages: bizmanage pull --include pages.
2. Create src/pages/operations-dashboard.html and operations-dashboard.json.
3. Use <bmml-data-src> to load records or reports.
4. Validate and push only that page: bizmanage validate --file src/pages/operations-dashboard.html, then bizmanage push --page /operations/dashboard.

Add a customer action that opens a prefilled form

goToPageByUrl('/add/tasks?pre_data_customer=' + record.id + '&initial_name=Follow up with ' + encodeURIComponent(record.name));

Add a row action that calls a backend script

Modal.confirm('Run sync for this customer?').then(function () {
  return $http.post('/scripts/run/sync_customer', { customer_id: record.id });
}).then(function () {
  notify('Sync started');
});

Seed lookup data

src/objects/statuses/data/default-statuses.json
[
  { "internal_name": "new", "name": "New" },
  { "internal_name": "in_progress", "name": "In Progress" },
  { "internal_name": "done", "name": "Done" }
]

Targeted deployment

bizmanage push --include data --object statuses
bizmanage push --script sync_customer
bizmanage push --action customers.sync_customer

Public Boundary

What this documentation intentionally includes and excludes.

This site is public. It documents customization capabilities and safe usage patterns. It should not contain customer data, secrets, private infrastructure details, internal recovery plans, or production credentials.

Included

• CLI commands and options.
• BMML elements, variables, filters, functions, forms, and URLs.
• Customization file structure.
• Publicly useful API and CRUD patterns.
• Safe examples for pages, actions, scripts, reports, and data files.
• AI prompt guidance.

Excluded

• Real API keys, tokens, passwords, credentials, or account secrets.
• Customer-specific data or business logic that is not meant as an example.
• Internal server deployment steps and recovery plans.
• Private billing, provider, or infrastructure configuration.
• Anything that would bypass policy checks or expose protected data.

Review checklist before future publishes

1. Search for api_key, token, password, secret, private, and real email/customer data.
2. Keep examples generic.
3. Document capabilities, not internal operational access.
4. Verify the site after deployment.