Setup Guide

Brisk managed documentation

Tasks and Screens

Tasks and Screens

Custom Fields

Custom Fields

Purpose and when to use this screen

Custom Fields adds organization-specific information to supported Brisk record types when no standard field represents the requirement. Use it for durable business facts that need consistent entry and lookup—not for temporary notes, calculations that belong in code, or a duplicate of an existing field.

Configure custom fields

Brisk Custom Fields fields screen displayed with fictional documentation-demo data.
The Custom Fields fields screen in the Brisk documentation demo.
  1. Search the target form and existing custom-field list before creating anything.
  2. Select Create New Custom Field and choose the target application/model carefully. This determines which records and forms receive the field.
  3. Enter a clear business-facing name/label and select the data type that matches expected use. Define choices or defaults where supported.
  4. Decide whether the field is required. A required field can block creation or editing of existing records that do not yet have a value.
  5. Save, then open create, detail, and edit screens for the target record and verify display, validation, permissions, and list/report behavior.

Design fields for real work

Use one concept per field and stable vocabulary. Prefer a controlled choice when the business will filter or report by the value; prefer text only when variation is genuinely needed. Include units in the label for measurements. Avoid placing passwords, payment credentials, health data, or other sensitive information in a general-purpose custom field unless access, retention, and disclosure have been explicitly designed.

Working safely and effectively

Changing the target model, type, choices, or required behavior after data exists can make earlier values misleading or unusable. Inventory affected forms, imports, API integrations, reports, and templates before changing a definition. Test significant changes on copied data, plan how existing rows will be populated or converted, and communicate the effective date.

Retire a custom field

Export or otherwise preserve required values before deletion. If the business may need historical data, stop using the field and remove it from workflows through a controlled migration instead of immediately deleting its definition. Verify that no report, template, import, or integration still expects it.

Tasks and Screens

Local Workstation Setup

Local Workstation Setup

Purpose and when to use this screen

Local Workstation Setup stores Point of Sale identity and cash-drawer selection in this browser on this machine. Use it for a fixed register, shared counter computer, or browser profile that should consistently identify itself. These values do not follow the user to another browser or device.

Configure this workstation

Brisk Local Workstation Setup workstation screen displayed with fictional documentation-demo data.
The Local Workstation Setup workstation screen in the Brisk documentation demo.
  1. Enter a short, recognizable Workstation Name, such as Front Counter 1 or Service Desk.
  2. If multi-cash-drawer support is enabled, select the Cash Drawer physically used by this register.
  3. Select Save and confirm the success status.
  4. Open Point of Sale and verify that the expected workstation/drawer context appears before accepting cash.

Brisk saves the workstation name and drawer identifier in browser-local storage and synchronizes the selected drawer through the workstation endpoint. It also recognizes the older invoice cash-drawer browser key so an existing register can migrate without silently losing its selection.

Clear or replace the local setting

Use Clear Local Setting before repurposing the machine, changing the register’s physical drawer, deleting the browser profile, or handing the device to another location. Then save the new identity and test it. Clearing browser site data outside Brisk also removes these local values.

Cash-control implications

The selected drawer affects how cash activity is attributed and later reconciled. Do not select a convenient drawer that is physically elsewhere. If multi-drawer support is disabled, the drawer control and Save action are unavailable; an administrator must enable and configure the feature rather than using browser tools to force a value.

If the selection does not persist

Confirm the browser allows local storage, the page is not in a temporary/private session, and the user can access the selected drawer. Clear the setting, reload, save again, and verify in Point of Sale. Treat shared browser profiles and automated browser cleanup as workstation configuration risks.

Tasks and Screens

Data Import

Data Import

Purpose and when to use this screen

Data Import loads supported CSV datasets while preserving a run record, row-level diagnostics, source-system identity, and dry-run/apply distinction. Use it for controlled migration or conversion—not as a shortcut around normal validation or as a replacement for database restore.

Choose an import workflow

Brisk Data Import start screen displayed with fictional documentation-demo data.
The Data Import start screen in the Brisk documentation demo.

Use Master Data Import for accounts, items, customers, vendors, payment terms, taxes, item classes, customer classes, and units of measure. Use Historical Import for archived business transactions that must remain searchable without becoming ordinary live operational records. Download/use the headers shown for the selected dataset rather than guessing column names.

Import master data

Brisk Data Import master screen displayed with fictional documentation-demo data.
The Data Import master screen in the Brisk documentation demo.
  1. Select the dataset and identify the source system.
  2. Choose the lookup strategy that matches reliable source identifiers. Auto is not permission to accept ambiguous matches.
  3. Upload the CSV and run File Check/Preflight. Fix blocking errors and review warnings.
  4. Leave Dry Run selected for the first import. Review created, updated, skipped, warning, and error counts.
  5. Decide whether existing records may be updated, missing related records created, opening balances applied, and blank source values allowed to clear existing data.
  6. Apply only after the dry-run result and representative row mappings are approved.

Opening customer/vendor balances and account balances have accounting consequences. Confirm effective date, offset/control accounts, duplicate prevention, and reconciliation plan before applying them.

Import historical data

Brisk Data Import history screen displayed with fictional documentation-demo data.
The Data Import history screen in the Brisk documentation demo.

Select the transaction type, source system, and CSV. Start with dry run, verify external/document IDs, party, transaction date, reference, memo, amounts, and line detail. Decide whether an existing archive record may be updated and whether existing lines should be replaced. Historical archive entries support lookup and migration history; do not assume they post to inventory, receivables, payables, or the general ledger.

Review import runs

Brisk Data Import runs screen displayed with fictional documentation-demo data.
The Data Import runs screen in the Brisk documentation demo.

Open the saved run and review import type, dataset, filename, source system, options, timestamps, status, counts, lookup strategy, and up to the recorded row-level issues. Download failed rows, correct the source CSV, and retry from the run link so dataset/source context is preserved. Do not repeatedly apply the entire original file when only failed rows need correction unless the chosen upsert keys make that safe.

Look up imported history

Brisk Data Import records screen displayed with fictional documentation-demo data.
The Data Import records screen in the Brisk documentation demo.

Filter Historical Lookup by transaction type and search document number, external ID, party, reference, memo, or lookup key. Open a representative sample across dates and transaction types and verify header/line totals and source identifiers. The archive retains up to the displayed search scope; use run/detail views for precise diagnostics.

Working safely and effectively

Back up the database and media first, test on a non-production copy, and retain the original file, transformed file, mapping rules, run IDs, approvals, and reconciliation results. After apply, verify record counts, duplicates, relationships, balances, permissions, and representative downstream screens/reports. Roll back by restoring the tested backup when the import’s effects cannot be safely and completely reversed through normal records.