Approval Matrices

matrices are a data driven alternative to conditions instead of encoding thresholds and combinations in configuration, you store them as rows in a table each matrix line holds a set of criteria and — when a submitted record matches — the associated path or step is triggered use matrices when you have many threshold combinations (e g , discount × product family × region) that would be painful to maintain as conditions you want a non admin team (commercial, sales ops) to own the thresholds matrix lines can be edited without touching the approval process you want thresholds to be updatable while the process is active matrices are the only part of the approval configuration exempt from process versioning docid\ azjll0xmtil4tp vobxqa — changes take effect immediately on existing active processes note matrices can only be used on paths and steps, not as entry criteria on an approval process itself how a matrix evaluates a matrix is defined as a matrix record ( appro matrix c ) — sets the parent object, and optionally a child object a set of matrix fields ( appro matrix field c ) — the mapping between columns in the matrix line and fields on the record being approved custom fields on the appro matrix line c object — one per dimension you want to key on (e g , product code, max amount) a set of matrix lines — the actual data rows at runtime, approvals pro iterates over the matrix lines, evaluating each mapping against the submitted record (and optionally its children) if any line matches, the path / step is triggered warning entry criteria + matrix = or if a step has both entry criteria and a matrix attached, it triggers when either evaluates to true this is unintuitive — most admins assume and pick one mechanism per step if you need combined logic, consolidate everything into the matrix step 1 plan the matrix before you build it write out the decision table on paper first for each dimension, answer which field does it live on? (parent record, or a child like a line item?) what's the comparison operator? ( = , > , < , match ) will blank/null values ever appear? (matrix evaluation on null fields can throw errors — ensure source fields are always populated, or filter them out upstream ) example plan example plan route quotes to approval when a line item for a given product code exceeds a max amount threshold dimension field lives on operator product code productcode opportunitylineitem (child) match max amount amount opportunity (parent) greater than step 2 create the matrix record go to the matrices tab click new fill in field value matrix name a human readable label (e g , discount approval by product ) object api name of the parent object being approved (e g , opportunity ) child object optional api name of a child object, if the matrix references child record fields (e g , opportunitylineitem ) child link field required if child object is set api name of the field on the child that points at the parent (e g , opportunityid ) multi hop relationships are allowed via dot notation (e g , parent r grandparentid c ) save step 3 add custom fields to the matrix line object each "column" in your matrix is a custom field on appro matrix line c create one field per dimension setup → object manager → matrix line → fields & relationships → new for each dimension pick the field type that matches your data (number for amounts, text for codes, percent for discount caps, date for windows) give it a clear label and api name add the new fields to the matrix line page layout so matrix maintainers can see them for the example above, create max amount c (number, 2 decimals) product code c (text, 50) step 4 map each matrix line field to the record matrix fields ( appro matrix field c ) tell approvals pro how to compare a matrix line field to the record being approved open the matrix record you created in step 2 click the related tab under matrix fields , click new fill in field example 1 (max amount) example 2 (product code) matrix field name max amount c (field on matrix line) product code c (field on matrix line) map to amount (field on opportunity) productcode (field on opportunitylineitem) map relation parent child operator greater match save available operators operator meaning valid field types match exact equality text, picklist, number, boolean not match not equal text, picklist, number, boolean greater matrix value is less than record value (triggers when the record exceeds the matrix threshold) number, date less matrix value is greater than record value number, date contains record value contains the matrix value text step 5 populate the matrix lines on the matrix record's related tab, under matrix lines , click new fill in the custom fields you created in step 3 set seq (sequence) — when multiple lines match, only the line with the lowest seq is used save , and repeat for each row in your decision table example matrix lines seq product code max amount 1 sku ent 001 100,000 2 sku pro 001 50,000 3 sku std 001 25,000 with these lines, an opportunity with a line item for sku ent 001 triggers approval when the opportunity's amount is greater than $100,000 step 6 attach the matrix to a path or step open the approval path or approval step that should use this matrix in the matrix based condition section (step) or in the path's matrix picker (path), select the matrix save no further field mapping is needed on the path/step — everything is declared in the matrix definition matrix driven approver assignment matrices can also resolve who approves — not just whether approval is needed to use a matrix for approver assignment add an approver field on appro matrix line c (e g , a lookup to appro approver c ) populate the approver column per line on the approval step, set the approver field to the matrix resolved value this pattern is common for routing e g , the same matrix that decides which deals need approval can also specify the regional director who approves them maintenance tips who owns the matrix? decide upfront commercial ops often maintains thresholds; the salesforce admin owns the schema document this in your runbook assign the right permissions matrix maintainers need read/create/edit on appro matrix c and appro matrix line c but do not need admin rights on the rest of approvals pro create a dedicated permission set audit changes enable field history tracking on matrix line fields so you can see who changed which threshold and when test in sandbox even though matrix changes are immediate, test new rows against representative records before adding them in production troubleshooting symptom likely cause fix matrix doesn't trigger when it should field on the record is null; matrix evaluation skips populate the field on the record (or add a default via formula / trigger) two lines should both match but only one triggers lowest seq wins by design re order seq, or split into two matrices changes to matrix lines don't take effect record page was loaded before the change refresh the record; matrix evaluation happens on page load child object mapping returns no matches child link field is wrong — e g , opportunitylineitem needs opportunityid , not a custom lookup verify via soql step triggers even when matrix doesn't match step also has entry criteria configured remove the entry criteria (see warning above — they combine as or) related entry criteria docid\ jueqw5ihkigwapzfrtszk — the conditions alternative to matrices configuring approval processes docid\ kcmpddjgungd5jvuo8ngj — where paths and steps are defined best practices docid\ h8xc9gykfudb7auncqlpu — matrix design dos and don'ts object model docid\ mvebvizbuokkqryr0cjui — matrix c , matrix field c , matrix line c schema