The Process Logic workbook is an Excel file that defines what a Process does. It contains the formulas, named ranges, and worksheet structure that the platform executes when a Process runs. The workbook holds no persistent data — all operational data is supplied to it at runtime from the database or from Process Parameters.

A starter Process Logic template is attached to this article. It provides the required named ranges, a consistent structure other configurators can follow, and built-in overflow protection. You don't have to use it, but any workbook you build must include the equivalent structure.

​

Three named ranges are mandatory in every Process Logic workbook.

ES_PARAMETERS is the starting cell where Process Parameter values are written at runtime. If the Process has three parameters, they are written horizontally from this cell — one value per column, in the order the parameters are configured. This cell reference must match the Spreadsheet Parameter Location set in the Process configuration.

ES_RESULT is the single cell that the platform reads to determine whether the Process succeeded. It must return one of three values: Success, Warning, or Failed. If it returns Failed, the Process is aborted, no data is written to the database, and any chained Processes are also terminated. Your workbook should include a formula in this cell that evaluates your logic and returns the appropriate value.

EU_NOTIFICATION is the named range for notification messages returned to the user. This range is defined in the template and typically sits on the energysys worksheet. Each row in the range represents one notification. If the first cell in a row is blank, that row is ignored. See Process Notifications for how to configure and write notification records.

​

The template establishes a standard colour-coded worksheet structure. Following this convention makes every workbook easier to understand and maintain.

Summary (grey tab) — documents the workbook: author, purpose, revision number, the parameters it uses, and a register of all worksheets. It also contains the overflow check columns used to detect when incoming data exceeds the workbook's configured capacity. Complete this sheet whenever you create or modify a workbook.

energysys (grey tab) — contains the system interaction area: the ES_PARAMETERS starting cell, the ES_RESULT cell, and the EU_NOTIFICATION range. This sheet manages the interface between the workbook and the platform.

Input sheets (blue tabs) — one sheet per Process Input. Each sheet receives the data loaded from a database object. No calculations should appear on input sheets. If a minor calculation is needed to build a lookup key, place it to the left of the input range and highlight it clearly.

Calculation sheets (red tabs) — contain the business logic. Organise these left to right in the logical order of execution. Keep formulas clear and break complex logic across multiple sheets rather than piling it onto one.

Output sheets (green tabs) — one sheet per Process Output. Each sheet contains the data to be written back to the database. Where possible, name the sheet after the target object.

Worksheet names should not contain spaces — use underscores to separate words. This prevents Excel from inserting quotation marks in formula references.

​

Process Inputs write data into named ranges in the workbook. You can define a named range as a full rectangular range, in which case the platform checks whether the incoming data fits and fails the Process if it exceeds the defined size. Alternatively, you can name only the top-left cell, in which case the data expands rightward and downward from that cell — but you must then implement your own overflow checks.

Process Output ranges must cover the full set of rows and columns you intend to write to the database. The column order must exactly match the attribute order of the target object. Blank rows are ignored. No additional columns are permitted beyond those defined in the object.

If you want column headings written to the workbook (useful for the Calculation Log), define a separate named range for the heading location — it requires two rows, one for attribute names and one for units.

​

The platform is strict about data formats when reading values from output ranges to write to the database.

Dates must be formatted dd/mmm/yyyy. DateTime values must be formatted dd/mmm/yyyy hh:mm:ss. Numeric columns must use an explicit numeric format with fixed decimal places — cells formatted as General are not reliable and will generate a warning notification. Boolean values must be T, TRUE, F, FALSE, or blank. Columns not marked as required in the object definition may contain null values. Extra columns beyond the object definition are not permitted.

​

Many Processes operate on multiple rows of data — for example, loading records for dozens of contracts or hundreds of transactions. The workbook must contain enough rows to handle the data it receives. If incoming data exceeds the configured row capacity, the Process should fail gracefully rather than silently truncating results.

The standard template includes columns on the Summary sheet to support overflow checks: Rows in Range (the configured calculation capacity), Actual (the number of rows received), and Overflow (a formula that fires when Actual exceeds Rows in Range). When an overflow is detected, the first notification row on the energysys sheet triggers a notification, and ES_RESULT should be set to Failed.

Do not remove the overflow notification row from the template. You may add additional notification rows below it.

​

Process performance is almost always a function of workbook design rather than system capacity. The guidance here applies to all Process Logic workbooks, regardless of complexity.

Keep Processes small and focused. A workbook that handles one logical step is faster to load, easier to calculate, and simpler to maintain than one that handles everything. If a workflow is complex, break it into smaller Processes and chain them. See Chain Processes in a Workflow.

Avoid placing logic immediately to the right of input data. If an object gains new attributes, the platform will write additional columns into the input range, potentially overwriting calculation columns placed to the right. Place calculations to the left of the input range or on a separate sheet.

Avoid placing logic below input ranges. If data volumes grow, new rows will be added to the input range, potentially overwriting logic placed below. Leave clear space below all input ranges.

Minimise expensive functions. NOW() is expensive — calculate it once in a dedicated cell and reference it elsewhere rather than calling it repeatedly. MATCH() is also expensive when called many times — calculate it once and reference the result. If your workbook contains large numbers of INDEX lookups, replacing them with OFFSET can improve performance.

Remove redundant formulas. Review the workbook periodically and remove any calculations that are no longer referenced, intermediate sheets that only pass values through, and columns that produce values never used.

Minimise cross-sheet references. Formulas that reference other worksheets calculate more slowly than local references. If a value from another sheet is used repeatedly, pull it into a local cell first.

Control workbook size. Design for the number of rows you actually need, with a sensible allowance for growth. Very large workbooks take longer to load into memory. Check occasionally whether Excel treats the sheet as extending further than your actual data by pressing Ctrl+End and deleting any surplus empty rows or columns.

​

Use consistent naming across all Process Logic workbooks. Named ranges for Process Inputs and Outputs should match the name of the object they relate to. Use upper case for Input and Output named ranges. Use lower case for local variables and intermediate ranges. Use consistent parameter names across all Processes — for example, always name a date parameter the same thing across every Process in your application, since filter reuse depends on consistent naming.

​

By default, each Calculation Log entry is named using the Process execution number, sequence number within a workflow, and the Process name — for example, 5519_001_Daily Calculation.xlsx. If you want the log entry name to reflect runtime context (such as which entity was processed or which date was used), you can override the Process Name portion by defining a named cell called ES_CALC_LOG_NAME in the workbook. The platform reads this cell at runtime and uses its value in place of the Process name. The execution number and sequence number are not affected. The cell can use a formula referencing parameters or calculated values to generate dynamic names.