Prequalification

Prequalification is the first step of the simulator. The seller types in the details the evaluation asks for, usually a document number. AltScore runs the evaluation the operator chose in the Hub and reads back one word, the decision. That word decides which of four screens the seller sees: approved, needs review, rejected, or a check that could not finish. Along with the decision, the evaluation can also return the customer's approved limit, a maximum term and a report the seller can download.

The seller never chooses what runs. The operator picks the evaluation, the words that count as a rejection or a review, and whether a customer who does not qualify can still be simulated. The evaluation is a workflow built in the Workflow Builder. All of these settings are covered in Configuring the Portal. This page explains what the seller sees at each point and why. The last sections are written for the workflow author who builds the evaluation.

A prequalification is not a credit offer, and the screen says so at every stage. Under the form, the wait and every result, the same line stays visible: "Pre-qualification is not a credit offer. Final approval is subject to file review and signature of the documentation."

The Simulator at a Glance

The simulator is a single screen with a ladder of steps beside it, headed Credit simulation. The ladder lists the steps the organization configured, then two that are always there:

Steps are numbered by their position, so when the organization's simulator has no prequalification step, the operation data is step 1. The seller can tap back to an earlier step but cannot jump ahead. Once a simulation is saved, Summary becomes reachable, and tapping Document also lands there.

On a screen up to 1000 pixels wide, which in practice means a phone, the ladder becomes a bar above the content. The bar shows the current step's name, its position as n/N, and a back arrow when the current step has an earlier one. The arrow does not appear on Summary or while a saved simulation is being edited. A round + button in the middle of the header, in the portal's primary color, starts a new consultation. On wider screens the ladder is a side rail, with a New consultation button under it.

Before It Can Run

Only certain workflows can serve as the prequalification. A workflow qualifies when it is in the Recommendation category, has an alias, is published and is not archived. The portal works from the 50 most recently updated of them, each in its latest version. The operator picks one in the Hub under Evaluation that runs, but that list shows more than 50, so an organization with more than 50 published evaluations can pick one the portal does not see, and the seller then reads the "no longer published" message. See Publishing Workflows for how a version becomes the published one.

When nothing can run, the form does not appear. In its place, the step shows the title Pre-qualification is not available yet and one of three explanations, depending on what is missing:

One more case blocks the step. When the search scope is limited to the seller's routes (see below), a seller with no route assigned sees You do not have any route assigned yet with "Without a route you cannot pre-qualify customers. Ask your administrator to assign you at least one." Under the organization-wide scope, having no routes does not block prequalification.

The Form

The step opens with the heading Step 1 · Pre-qualification, shown on desktop only. Under it come the title Check the customer’s available limit and the line "Enter their details and we’ll check how much credit they have available." The card below holds the form. The evaluation's name and description are never shown: the seller cannot change the evaluation, so there is nothing for them to decide there.

Fields

The fields are the evaluation's inputs, in the order the workflow declares them. Each field is labeled with the Label the workflow author gave the input. When the author gave none, the field reads Requested detail {number}, where the number is the field's position. The author's Description appears under the field. A field whose input has Required turned on must be filled before the check can run; the others can be left empty. Inputs created in the Workflow Builder start with Required off. The button that runs the check is Validate customer.

Already a Customer?

When the operator turns on Customer search in this step in the Hub and the evaluation asks for at least one input, an Already a customer? block appears above the fields. Its help line reads "Search for an existing customer to fill in their document automatically. Pre-qualification still runs." The box searches the way the Customer Book does and shows up to six matches, each with the customer's name and business key.

Picking a customer fills only the inputs the operator mapped to an identity under Which identity fills each input. An input with no mapping, or one whose identity this customer does not have, stays empty for the seller to type. Nothing is ever guessed, because the document that goes into the evaluation is the one the check runs against. Picking a customer only fills fields: the check itself still runs.

The block reports what happened:

Which Route

The step never asks for a route. What happens with routes depends on the Search scope set in the Hub.

Only the customers of their routes. The check runs on the seller's first route, and the search box looks only inside that route. When the check finishes successfully and identifies the customer, AltScore adds the customer to that route if the seller did not already have them. This is how a newly prequalified customer ends up in the seller's book.

Every customer in the organization. No route is used. The search box covers the whole organization, and the customer is not added to any route. This lets sellers who have no routes prequalify.

Waiting for the Result

After Validate customer, the form gives way to a spinner and the title Qualifying the customer. Under it, four lines rotate every 1.6 seconds and stop on the last one: "Checking the customer's details…", "Checking credit standing…", "Working out the limit on the line…" and "Putting the result together…". The lines show progress. They do not track what the evaluation is actually doing at that moment.

The check runs on AltScore's side, so the seller does not have to stay on the screen. They can go to another part of the portal and come back, the wait picks up again, and the result appears as soon as it is ready. Reloading the page is different: it starts the step over. Only the seller who started a check can see its result.

If three minutes pass with no result, the spinner is replaced by This is taking a while and the line "The check is still running. You can check again now, or come back later — nothing is lost." The Check again button asks for the result once more. If it is still not ready, the screen stays as it is, and the result still appears on its own as soon as the check finishes.

If the Evaluation Changed Meanwhile

Publishing a new version of a workflow replaces the version the portal loaded when the step opened. The portal follows the evaluation by its alias. When the version it holds is gone, it finds the new one and retries once on its own, and the seller does not notice. If the retry also fails, the seller sees "The prequalification changed while you were working. Reload the page to use the new version."

How the Decision Becomes a Screen

Where the Decision Comes From

AltScore looks for the decision in three places, in this order, and uses the first one it finds:

1. A decision value at the root of the evaluation's output.
2. The engine's final verdict for the run.
3. The decision of the last rule tree in the output.

A run that finishes has not necessarily approved anyone. A rejection is also a run that finished. The screen follows the decision, never the mere fact that the run completed.

Matching the Word

The decision is compared ignoring upper and lower case and accents, so Revisión, REVISION and revision are the same word. The operator's lists from the Hub are checked first. Built-in words apply to anything the lists do not catch:

The lists are checked in the order shown, so a word that appears in two lists goes to the first one that contains it. A missing or unknown decision is never shown as a rejection: telling a seller their customer was declined when nothing declined them would be the worse mistake.

An approved word is not enough on its own. The approved screen also needs the run to have finished successfully and identified the customer. If either is missing, an approved decision lands on the review screen.

The Result Screens

Approved

The screen opens with the heading Step 1 · Customer pre-qualified (on desktop), the customer's name as the title and the organization's business key under it. When it applies, an Assigned to another seller pill sits next to the business key (see Customers on Other Sellers' Routes).

A dark panel follows: Pre-qualification result, Approved, and the line "The customer is pre-qualified. The exact amount is set with the credit conditions." When there is an approved limit to show, the panel shows it too (see The Approved Limit).

The actions sit in a row under the panel:

When continuing is not allowed, a line explains why: "This result does not allow going ahead with the simulation. Try another customer or let your administrator know."

Needs Review or No Data

This screen has no customer header: it goes straight to an amber panel headed Result, with one of two titles:

The panel offers Continue to simulation when continuing is allowed and Check another customer always. Download report sits on the right when the evaluation produced a report. If the evaluation published an approved limit, the panel shows it here too. When continuing is not allowed, the same "This result does not allow going ahead with the simulation…" line appears under the panel.

Rejected

The screen opens with the heading Step 1 · Customer rejected (on desktop), the customer's name and the business key, plus the Assigned to another seller pill when it applies. A clay-colored panel follows: Pre-qualification result, Rejected and the line "The customer has no limit available right now. The consultation is recorded in the history."

Despite that line, the consultation reaches the history only if the seller goes on and saves a simulation for the customer. The history lists saved simulations, nothing else. See Prequalifications in the History.

The main button is Try another customer. Continue anyway appears beside it as a secondary option, only when the organization allows it. Download report appears when the evaluation produced a report. Under the panel, one of two lines appears. When continuing is allowed: "You can continue anyway: the simulation is created and the report records the rejection." When it is not: "This result does not allow going ahead with the simulation. Try another customer or let your administrator know."

A rejection does not end the sale unless the organization says so. When the seller continues, the rejection is saved with the simulation and printed on its document; see Saved Simulations and History.

Check Incomplete

When the run fails before finishing, nothing was judged. The screen shows an amber panel, Check incomplete, with We could not complete the check and "This was a problem running the check, not a decision about the customer. Try again in a few minutes." Its only button is Retry, which clears the attempt and returns to an empty form. There is no report, and this screen never lets the seller continue.

Customers on Other Sellers' Routes

A seller can prequalify a customer who is already on another seller's route. The result still shows that customer and the sale can go on as usual. With the route-only scope, when the run finishes successfully and the customer is not yet on any of this seller's routes, the customer is added to this seller's first route and the Assigned to another seller pill appears next to the business key. Both sellers then have the customer in their book. If the customer is already on one of this seller's routes, nothing is added and no pill appears, even when another seller has them too. With the organization-wide scope, no route is touched, and the pill appears whenever the customer is already on any route, the seller's own included. The pill is part of the customer header, so it shows on the approved and rejected screens, not on the review screen.

The Approved Limit

The evaluation can return the limit it approved. The limit is shown to the seller only when Show approved amount is on in the Hub, which is the default.

On the approved screen, and on the review screen when there is a limit, the panel shows Available limit with the amount and a footnote. The rejected screen never shows it. Normally the footnote reads "The amount financed starts at this figure and cannot go above it." For a limit of zero it reads "The evaluation approved a limit of zero: there is nothing to finance." Zero is an answer from the evaluation. It is not the same as returning no limit at all.

The limit carries into the next steps. It becomes the starting amount in the operation data step and the ceiling in the payment plan step. It also appears as Pre-qualified limit in the summary. See Operation Data and Payment Plan.

When Show approved amount is off, AltScore never sends the figure to the seller's device, so it cannot be found anywhere in the portal. The same happens when the evaluation returns no limit, or when the Hub says No approved amount is used. Nothing about a limit appears anywhere: no figure, no starting amount, no ceiling and no summary row. The seller types the amount. Turning the figure off leaves everything else as it was: the decision, the notices and the maximum term still arrive.

Continuing to the Operation

Whether a result lets the seller go on to the operation data depends on two Hub settings: the Which answers let the seller continue list and the Allow continuing anyway switch, which is on by default.

Each screen uses its own button to continue: Simulate the credit on the approved screen, Continue to simulation on the review screen and Continue anyway on the rejected one. Two more conditions apply in every case. The run must have identified the customer, because there has to be someone to simulate for, and the organization's simulator must have a step after prequalification.

The rule also holds when the simulation is saved. Suppose the organization has saved its portal configuration with the prequalification step on and Allow continuing anyway off. Then a simulation without an accepted prequalification is refused when saved, even if the request did not come from the portal screens. The seller would see "Your configuration requires a pre-qualification before saving the simulation. Go back to the pre-qualification step and validate the customer." See Errors, Warnings and Limits.

One case does not line up. With no continue list and Allow continuing anyway off, a NO DATA result still shows Continue to simulation, and so does a review word that is not one of the built-in approval or review words. The seller can fill in the operation and the plan, and then the save is refused with that message. To let those words through, list them in Which answers let the seller continue, together with your approval words.

Notices

Under the result, a Run notices box lists the notices the run produced, word for word. They can come from the workflow's own Notice nodes, from data sources or from the engine. Errors appear in red and everything else in orange. The box shows at most five of the run's notices, errors first, and cuts each message at 300 characters. A notice is often the whole explanation: when a data source rejects the document number the seller typed, that message can show up here, next to the result it caused.

The portal adds its own warning, after the run's notices, when a run finished but left out something it needs. Both are written for the workflow author, not the seller:

• "The workflow completed but its output did not include 'decision'. Review the workflow's output configuration."
• "The workflow completed but its output did not include the customer (borrowerId), so there is no way to continue. Review the workflow's output configuration."

If a data source fails during the run, the decision may rest on incomplete data. The portal has no separate signal for this. Whatever the run reported about the failure appears among the notices.

Prequalifications in the History

The history lists saved simulations only. A prequalification that never reaches a saved simulation is not there: a seller who prequalifies a customer, gets a rejection and stops will not find that consultation in the history, whatever the rejected screen says.

The Approved badge, with the footer Pre-qualified, not simulated, and the Rejected badge, with No limit available, belong to a saved simulation that has no payment plan. They describe a simulation the seller saved, not a prequalification on its own. See Saved Simulations and History.

Starting Over

Check another customer and Try another customer start the step over for a new customer. They clear the result, the customer, the inputs, the amount, the operation number and the operation date. Nothing from the previous customer carries over, so an amount seeded from one customer's limit is never offered to the next. New consultation in the rail, or the + on a phone, starts the whole simulator from scratch.

What the Evaluation Should Return

This section is for the person who builds the evaluation in the Workflow Builder. The portal reads the following from the run's output:

A variable named in the Hub is the only one read for that value: the list of common names applies only when no variable is named. A typo in the Hub therefore reads as "no limit", not as the next name on the list.

The fields come from the workflow's inputs. Give each input a Label, plus a Description where it helps, because the seller sees exactly those. Turn on Required for every input the seller must fill. An input with Required off can be left empty and the check still runs. The workflow needs an alias for the portal to find it again after each publish; see Getting Started.

Things to Know

The seller never picks the evaluation. Only the one chosen in the Hub runs. If it stops being published, the step stays blocked until it is published again or another one is chosen.

Finishing is not approving. A run that completes with rechazado is a successful run with a rejection in it. The screen follows the decision.

An unknown word is not a rejection. A misspelled decision, or a new word the lists do not cover, shows NO DATA and by default still lets the seller continue. If the evaluation uses words of its own, list them in the Hub.

Your own review words show as NO DATA. The title of the amber screen comes from the built-in words. A word that reaches the review screen through Which answers need review but is not one of the built-in words of any kind (approval, rejection or review), such as pendiente, shows the title NO DATA and its body rather than NEEDS REVIEW. A built-in rejection word such as no, listed there, shows NEEDS REVIEW. The screen offers the same buttons either way, but with no continue list and Allow continuing anyway off, the save is refused for these words; see Continuing to the Operation.

Review words in a continue list. Once Which answers let the seller continue has words in it, a review word that is not also in that list can continue only through Allow continuing anyway. With that switch off, the review screen shows the "does not allow going ahead" line.

The limit only shows when the evaluation returns it. Prequalification is the only place a limit comes from. With no limit, the next steps open without a starting amount or a ceiling.

Prequalifying can add a customer to the seller's routes. Under the route-only scope, a check that finishes successfully adds the customer to the seller's first route, unless the customer is already on one of this seller's routes, and even when the customer already belongs to someone else's route.

A prequalification alone is not in the history. Only saved simulations are listed. A rejected customer the seller did not go on with leaves no trace there.

A publish while the seller is working is handled once. The portal finds the new version and retries by itself. If that fails, a reload fixes it.