Sample Workflow — Loan / Credit Decisioning

This walkthrough shows how a real lending team uses the Decision Rule Engine to automate their loan application decisioning process — from initial eligibility check through final approval or decline.

It's written as a business story first, with the rule-building details after. Reading it end-to-end takes about 15 minutes; building it yourself in a Sandbox takes another 30–45 minutes.

💡 What this teaches you: How to break a real-world business decision into multiple connected rules — and how DRE handles the routing for you so you don't have to.

The Business Story

Meet Riverside Lending

Riverside Lending receives loan applications through their Salesforce-based intake portal. Until recently, every application went through a three-step manual review:

1. Sarah in operations checked basic eligibility — age, employment, state of residence, minimum income

2. Marcus on the credit team pulled the credit score and calculated debt-to-income (DTI)

3. Priya, a senior underwriter, made the final approval call and set the loan terms

Applications took 2–3 business days to process, and Sarah, Marcus, and Priya spent most of their time on routine cases that didn't need their judgment. The interesting applications — the edge cases that genuinely needed human review — were getting buried under the volume.

The decision: Move the routine work into DRE so the team can focus on the edge cases.

The Goal

Riverside wants DRE to handle the straightforward cases automatically:

• Clear approvals (good income, good credit, low DTI) → auto-approve and notify the customer

• Clear declines (failed eligibility or weak credit) → auto-decline with a clear reason

• Edge cases (borderline credit, unusual employment, missing data) → route to Priya for manual review

Same business rules. Same outcomes. Just done in seconds instead of days.

The Workflow at a Glance

Here's the decisioning flow as a picture:

              [New Loan Application]
                       │
                       ▼
           ┌───────────────────────┐
           │ 1. Basic Eligibility  │
           │    (age, employment,  │
           │     state, income)    │
           └───────────────────────┘
              Passed │  │ Failed
                     │  └──────────────┐
                     ▼                 ▼
           ┌───────────────────────┐  ┌──────────────┐
           │ 2. Credit Check       │  │ 4. Decline   │
           │    (score, DTI)       │  │    Notice    │
           └───────────────────────┘  └──────────────┘
              Passed │  │ Failed
                     │  └──────────────┐
                     ▼                 ▼
           ┌───────────────────────┐  ┌──────────────┐
           │ 3. Final Approval     │  │ 4. Decline   │
           │    (set loan amount)  │  │    Notice    │
           └───────────────────────┘  └──────────────┘
                     │
                     ▼
                [Approved]

Four rules. Three possible outcomes (Approved, Declined, or — with optional changes — Manual Review).

The Four Rules in Plain English

Before we get into how to build them, here's what each rule does in everyday language.

Rule 1 — Basic Eligibility

"Approve to continue if the applicant is at least 18, currently employed or self-employed, lives in a state we serve, and earns at least $25,000 a year."

This rule weeds out applications we cannot legally or operationally process — before we spend money on a credit pull.

Outcome:

• ✅ Pass → Go to Credit Check

• ❌ Fail → Decline (with reason)

Rule 2 — Credit Check

"Approve to continue if the applicant has a credit score of 680 or higher AND a debt-to-income ratio under 40%."

This is the financial creditworthiness gate. We only get here if Basic Eligibility passed.

Outcome:

• ✅ Pass → Go to Final Approval

• ❌ Fail → Decline (with reason)

Rule 3 — Final Approval

"Set the application status to Approved. Set the approved loan amount equal to what the applicant requested."

This is the terminal positive outcome. It only runs if both prior rules passed.

In a more sophisticated version, the approved amount might be computed from a formula (e.g., 4× monthly income, capped at the requested amount). For learning, we keep it simple.

Outcome:

• ✅ Pass → Application is Approved

Rule 4 — Decline Notice

"Set the application status to Declined. Record the reason."

The fallback rule. It runs whenever an earlier rule fails — providing a consistent, written decline reason for the customer.

Outcome:

• ✅ Pass → Application is Declined

What's Happening Behind the Scenes

When a new application is submitted (either by an applicant or by your intake team), this is what unfolds:

1. DRE evaluates Basic Eligibility. Reads the application fields, checks the four criteria.

2. Based on the outcome, DRE picks the next rule automatically. Passed? → Credit Check. Failed? → Decline Notice.

3. The same routing happens after Credit Check. No human in the loop.

4. A terminal rule runs (Final Approval or Decline Notice) — setting status and any other fields.

5. The application is now in its final state, with a complete audit trail of every rule that ran, every condition checked, and every value compared.

Total elapsed time: A few seconds.

This automatic routing is called Sequential Rule Execution. Your Salesforce admin configures the chain (which rule follows which outcome) — you, the business user, design the rules themselves.

What This Looks Like to a Reviewer

When Priya opens an application after DRE has run, she sees:

• Application Status: Approved / Declined / Under Review

• Approved Loan Amount: Populated (or blank if declined)

• Decline Reason: Populated (if declined)

• Decision Rule Outcome panel: A clear summary showing which rules ran, in what order, and what each one decided

If she wants to dig deeper, she can open the Result Summary and Result Items records to see the exact values DRE evaluated. This is critical for:

• Audit trails — regulatory compliance, internal reviews

• Disputed decisions — when an applicant calls and asks "why was I declined?"

• Quality control — checking that the rules are working as intended

Building the Workflow Yourself

If you want to build this in your Sandbox, here's a high-level guide. (For step-by-step screens, refer back to the Quick Start — the mechanics are the same; you're just doing them four times.)

Before You Start

You'll need a custom Loan Application object in Salesforce. If it doesn't exist, ask your admin to create it with these fields (or adapt to your actual schema):

💡 Don't have this object? Your admin can create it in 15 minutes. Or, for learning purposes, adapt the workflow to use the standard Opportunity object instead — most of the same concepts apply.

Rule 1 — Basic Eligibility

Name: Loan - Basic Eligibility Object: Loan Application

Conditions (all must pass — combine with AND):

Action:

💡 Why "All"? As soon as DRE starts evaluating the application, we want the status to reflect that — Under Review. The final status (Approved or Declined) gets set by a later rule.

Rule 2 — Credit Check

Name: Loan - Credit Check Object: Loan Application

Conditions (both must pass — combine with AND):

No actions on this rule. It just decides whether to route to Final Approval or Decline.

💡 Intermediate rules often have no actions. They're "switches" that route to the next rule. The actions live on the terminal rules at the end of each path.

Rule 3 — Final Approval

Name: Loan - Final Approval Object: Loan Application

Condition (just a sanity check):

Actions:

💡 About "Computed Field Value": This Assignment Type lets you copy a value from another field on the record. Here, we set the approved amount to whatever the applicant requested. In a real workflow, you'd likely use a formula to cap this based on income or other factors.

Rule 4 — Decline Notice

Name: Loan - Decline Notice Object: Loan Application

Conditions: None required (or a trivial placeholder if your version of DRE requires at least one — ask your admin).

Actions:

Wire the Rules Together

The final step — chaining the rules so they run in sequence based on outcomes — is configured by your admin in DRE's metadata settings. You give your admin this routing logic:

After Basic Eligibility: - Passed → run Credit Check - Failed → run Decline Notice

After Credit Check: - Passed → run Final Approval - Failed → run Decline Notice

Final Approval and Decline Notice end the chain.

Your admin translates this into the JSON configuration DRE needs. See Sequential Rule Execution for the technical details (admin-focused).

Test It Like a Business User Would

Once the four rules are built and chained, test all three paths.

Test 1: A Solid Application (should Approve)

Create an application with:

• Age: 30

• Employment: Employed

• State: (one you support)

• Annual Income: $80,000

• Credit Score: 720

• Monthly Debt: $1,500 (gives DTI ≈ 22.5%)

• Requested Amount: $25,000

Run the chain (or trigger it from the application record). Expected: Status = Approved, Approved Amount = $25,000.

Test 2: A Borderline Application (should Decline at Basic)

Same as above, but change Age to 17.

Expected: Status = Declined, Decline Reason populated. Basic Eligibility failed, Decline Notice ran.

Test 3: A Weak Credit Application (should Decline at Credit Check)

Restore age to 30. Change Credit Score to 620.

Expected: Status = Declined, Decline Reason populated. Basic Eligibility passed, Credit Check failed, Decline Notice ran.

For each test, open the Decision Rule Outcome panel to see the full audit trail of which rules ran and what they decided.

What This Example Teaches

This workflow demonstrates patterns you'll use again and again in production DRE:

Variations to Try

When you're comfortable with the basic chain, try extending it:

💡 Add a Manual Review Path

For borderline credit scores (e.g., 600–679), route to a Manual Review rule instead of declining. This is where DRE earns its keep — automating the easy cases, escalating the genuinely difficult ones.

💡 Use a Lookup Instead of Hardcoded States

Instead of listing supported states in the rule itself, create a Supported States lookup table. Your operations team can add/remove states without changing the rule — a cleaner, more maintainable approach.

💡 Cap the Approved Amount

Instead of approving whatever was requested, cap the amount at (for example) 30% of annual income. Use a formula field on the Loan Application that calculates the cap, then set Approved Amount to the lesser of Requested or Cap.

💡 Trigger Automatically

Instead of someone clicking "Run Decision Rule" manually, have your admin set up a Salesforce Flow that runs the chain automatically when an application is submitted. Same rules; zero clicks.

A Few Realities to Keep in Mind

⚠️ Real loan logic is more complex. Production lending involves regulatory checks (KYC, AML), fraud detection, credit bureau integrations, and more. This example covers the decisioning layer — not the full underwriting system.

⚠️ Always validate in Sandbox first. Test all three paths with real-looking data before promoting any rule to Production.

⚠️ Watch out for empty fields. If a record has no Credit Score, the rule may evaluate as Unknown rather than Pass or Fail. Decide how your business wants to handle these (route to Manual Review is a common choice).

⚠️ Coordinate with your admin. You design the business logic; they handle the chaining configuration. Schedule a brief sync before they wire the chain so everyone agrees on the routing.

What to Do Next

You've now seen a realistic, end-to-end DRE workflow. From here:

• 🛠️ Adapt the pattern to your own process. What multi-step decision does your team make today that could be automated? Sketch it out the way we sketched the loan workflow.

• 📘 Read the User Guide for deeper coverage of conditions, operators, and rule patterns.

• ✅ Review Best Practices before you build production rules.

• 💡 Browse Use Cases for more inspiration.

If you have a workflow in mind and want help mapping it to DRE rules, talk to your DRE admin or contact support@cloudmaveninc.com.