nCino 301-COMMERCIAL-BANKING-CONFIGURATION: Approval Rules

A bank has launched a commercial lending workflow, but an approval task goes to the wrong group whenever a borrower requests a particular facility type. The issue is not necessarily a bad user decision: it may be a configuration rule whose conditions were not tested across all cases. A platform administrator has to translate policy into predictable behavior while preserving the information that auditors and frontline bankers need.

The historical nCino 301 Commercial Banking Configuration credential focused on configuring commercial lending workflows. Current preparation should follow nCino University guidance and the organization’s approved Salesforce/nCino implementation practices. The central distinction from the 201 functional course is building and validating the workflow rather than merely using it.

Translate a policy requirement into testable settings

A phrase like “high-risk loans require senior approval” is too vague to configure without knowing how risk is determined, which transaction types qualify and what counts as a senior approver. Administrators need precise acceptance criteria before changing screens or automations. A good configuration separates business rules from individual employee preferences and gives the institution a controlled method for updating those rules when policy changes.

Write requirements for a lending workflow that routes applications based on loan amount, product and risk class. Identify the fields that supply each condition and what should happen when one value is missing. Prepare positive and negative test cases, including a request that triggers two approval conditions. Explain why implementing the easy case first is insufficient evidence that routing is correct.

Keep object relationships and field semantics coherent

Because nCino solutions operate on the Salesforce platform, records, relationships, permissions and field definitions shape the user experience. Administrators should know when a field belongs to a borrower relationship versus a specific facility or credit package. Copying a value into several places can create contradictory versions, especially when one record changes after the package is created.

Map a borrower, a proposed loan, multiple guarantors and supporting documents. Decide which facts should be referenced from related records and which need to be captured for a historical approval snapshot. Consider how a report would answer the question “Which facilities are awaiting review for this borrower?” This tests the data model rather than the appearance of one form.

Configure approvals with clear ownership and escalation

Approval automation must respect delegations, role boundaries and exception procedures. A rule that sends every application to a general queue might appear functional but erase accountability. Conversely, hard-coding one employee as approver creates fragility when roles change. Administrators should account for reassignment, delegation, completion criteria and the state of records while an approval is pending.

Simulate an approving manager who is unavailable during a reporting deadline. Walk through the approved delegation path and make sure an unauthorized employee cannot approve the same request. Then introduce a revised credit amount that crosses a higher authority threshold. Test whether the prior approval remains appropriate or whether the loan must return for review, using the institution’s actual policy.

Build document and form configurations for reliable data

Templates, data mappings and conditional sections can reduce repetitive work, but a missing relationship or malformed field reference can generate an incomplete credit document. Template reliability requires testing with representative cases rather than one perfect record. Administrators should also decide whether a generated document is an informational draft, a controlled approval artifact or a customer-facing agreement, since the review process differs.

Create example cases with a corporate borrower, multiple guarantors and optional collateral information. Check that the resulting form shows the appropriate parties and does not substitute a contact name for a legal entity. Review date, amount and currency formatting. Test a missing optional section and a missing required input separately so users receive a meaningful warning rather than a partially completed output.

Release changes safely in a regulated workflow

Configuration changes can affect routing, reporting, security and historical records simultaneously. Sandboxes, version control where supported, regression tests and a documented release window help keep the production process stable. Administrators should understand the distinction between a defect, a business requirement change and an unauthorized policy exception. A working screen is not enough if audit history or access controls were weakened.

Plan a release that introduces a new credit product with a different approval path. Test existing products to confirm they still route correctly, verify who can see the new fields and document a rollback condition. Include a test for a loan already in progress when configuration changes. This demonstrates the administrator’s most valuable skill: protecting continuity while implementing new business requirements.