Vlocity Calculation Matrices: Lookup Tables and Versioned Rules

Start with the Salesforce meaning of matrix

In the Salesforce managed-package documentation, a Vlocity calculation matrix is a lookup table that matches supplied input dimensions to stored output values. It is different from a numerical matrix used for determinants, inverses or matrix multiplication. A typical question is which rate or allowance applies to a particular combination of attributes. This guide describes that managed-package concept; check the runtime and documentation that apply to your own Salesforce organization before following interface instructions. The local numerical Matrix Calculator cannot create, enable or execute a Salesforce calculation matrix.

Design the input and output contract first

Consider a fictional delivery rule table with inputs Region and Service and output BaseFee. Define three rows: North with Standard gives 8, North with Express gives 14, and South with Standard gives 10. The pair of input values identifies a row. A request containing Region=North and Service=Express should therefore return BaseFee=14. This is a data lookup, not 14 derived by multiplying the words North and Express. Write down field names, types and permitted values before loading rows so the caller and the table agree about the meaning of each supplied value.

Separate lookup results from later arithmetic

Suppose a calculation procedure retrieves BaseFee=14 from that table and then applies an illustrative handling amount of 3. Its total is 14+3=17. The lookup establishes which base fee applies; the procedure performs the subsequent calculation. Test those two stages separately. If the total is wrong because the lookup returned 8 for a Standard service request, changing the addition formula will not repair the selected row. Record the raw lookup output and the later calculated result so a reviewer can determine whether the problem belongs to data matching or arithmetic.

Respect uniqueness and missing combinations

Salesforce's standard-matrix documentation says that each input or set of inputs must be unique, while outputs can repeat. In the example, adding another North/Express row with a different fee creates an ambiguous design even if both rows have valid numeric outputs. South/Express is intentionally absent from the three-row example. Decide how the surrounding application should handle that unmatched combination and test the actual configured behavior; do not invent a zero fee merely because no matching row was found. A documented business default must be represented deliberately, rather than inferred from a missing record.

Review versions and effective dates

A standard calculation matrix can have multiple enabled versions. The managed-package documentation describes selection using start and end dates, effective date and priority; a higher priority number wins when the documented selection rules apply. If a caller supplies an effective date, test the version selected for that date as well as the current-date path. For a fictional fee change, create checks immediately before and after the intended transition and during any deliberate overlap. Keep the expected result tied to the version under test instead of treating the table's displayed newest row as proof of what every historical request should return.

Build and test within the correct organization

The official managed-package creation instructions begin with a new standard calculation matrix, followed by the appropriate version and input/output column definitions. Use those instructions for the actual interface, permissions and configuration supported in your organization. Start with a few fabricated rows before importing a large business table. Verify all three example matches, the missing South/Express combination and a deliberately misspelled field name through the actual caller. Save the supplied input and returned output for each case. A spreadsheet that looks correct is only one part of the evidence; the execution path must pass the intended values too.

Use the local JSON helper for its narrow purpose

The linked JSON Size Calculator can inspect whether a small demonstration payload is valid JSON and report its size. For example, a representation such as {"Region":"North","Service":"Express"} is a payload illustration, not a universal Salesforce endpoint contract. Field wrappers and invocation details depend on the actual integration. The local helper does not validate Salesforce permissions, select an enabled matrix version, match business rows or execute a calculation procedure. Use it only for the JSON inspection step, then verify the lookup and calculation in the configured Salesforce environment with its own supported tools.

Related guides

URL Encoding in Node.js: Components and Query Parameters

Choose encodeURIComponent, URLSearchParams or the URL API in Node.js. Compare spaces, plus signs, Unicode and safe decoding with reproducible examples.

Basic percent word problems

Basic percent word problems: calculation method, required inputs, worked check, limitations and a link to Basic Calculator.

Business Margin Calculation: Profit, Cost and Revenue

Calculate business profit margin with a checked example, distinguish margin from markup, and combine product margins using revenue weights.