Configuring the Portal
The seller portal has no settings screen of its own. Everything a seller can do, and everything they see, is decided by an operator in the Hub, once per organization. The seller never picks the evaluation that prequalifies a customer, the bot that onboards them or the channel it goes out on: those are your choices, and when one of them is missing, the seller's screen says what is missing and that an administrator has to fix it. The portal never fills the gap on its own, not even when only one option exists.
The settings are organized around three capabilities. You turn on what the portal should do, configure each capability underneath it, and the portal builds its menu from that. This page goes through the card section by section.
Where the Settings Live
Open the user menu, choose Settings, then, in the Configuration section, Seller portal. The entry only appears for users with the configurations.write permission. Without it, the page stays blank even when its address is opened directly.
Everything about the portal lives on that single card, titled Seller portal with the subtitle What your sellers can do from their phone.: the capabilities, prequalification, the operation, onboarding, simulation actions, seller access, branding (logo included) and the buttons. There is one place to save.
If your organization has never saved this configuration, the card opens with an alert: This organization has not saved this configuration yet: what you see below is the default composition and it does not apply until you save. Until that first save, sellers get a deliberately conservative portal: only the Customers section, with no prequalification, no simulation, no primary color and no document footer. The company logo is the exception: it does not depend on this save, so if one is uploaded the portal already shows it. Prequalification and operations stay off because they run workflows and create real operations, and nobody should get those by accident.
If the configuration cannot be loaded, the card shows We could not load the portal configuration. with a Retry button and no form at all. That is on purpose: a form filled with defaults after a failed load could be saved over your real configuration.
What Sellers Can Do
The first section, What they can do, carries the hint Turn on what this portal does; the rest builds itself. It has one switch per capability:
| Capability | Hint on the card | What the seller gets |
|---|---|---|
| See their book of customers | Each seller sees the customers on their routes. | The Customers section: the list, the search and the customer detail. See Customer Book. |
| Prequalify a customer | Check whether a customer qualifies before offering credit. | The prequalification step of the simulator. See Prequalification. |
| Build an operation | Simulate the credit and raise the application from the phone. | The operation data and simulation steps, the summary and the onboarding hand-off. See Operation Data and Payment Plan. |
Capabilities are set for the whole organization, never per route. Routes decide which customers belong to which seller; they never decide what a seller is allowed to do. Anything the configuration does not open is refused, even if someone tries to reach it directly; the seller sees This feature is not enabled for your organization. (see Errors, Warnings and Limits).
The settings under each capability stay visible while it is off, with the note These settings apply once the capability is on. You can prepare a capability before turning it on, and turning it off does not lose what you configured. Keep in mind that the settings of a capability that is off are still saved, and some are still checked: with Set here as the maximum-term source, an empty or invalid number blocks Save even while Build an operation is off (see Saving and Opening the Portal).
With all three switches off, a red alert reads With no feature on, the seller opens the portal and sees nothing. Turn at least one on. and Save is blocked with Turn at least one feature on.
The Customers capability has nothing else to configure. The portal never shows a customer's financial figures (see Customer Book), so there is no setting about them on this card.
Build an operation needs one more thing besides this switch: the organization's own-financing product feature. When that feature is not active, the portal hides the simulation step and refuses own-financing actions with Own financing is not enabled for your organization., whatever this card says. The full list of these messages is on Errors, Warnings and Limits.
How the Menu Is Built
You do not arrange the portal's menu: the Hub composes it from the switches every time you save, always in the same order.
- The Customers section, if See their book of customers is on.
- One simulator, whose steps are Prequalification (if Prequalify a customer is on), then Operation data and Simulation (if Build an operation is on).
A simulator with no steps is left out. Blocks and steps cannot be reordered, and the simulator always has those steps in that order. The names above are the ones the Hub stores; what the seller reads on each step is described on Prequalification.
The fixed order is not an arbitrary limitation. AltScore accepts at most one Customers section and one simulator, at most ten menu items, each with its own key, no repeated steps, prequalification only as the first step, and the simulation only after the operation data. Because the Hub builds the menu for you, a saved configuration always meets those rules and you never have to think about them.
Prequalification Settings
These settings sit under Prequalify a customer. What the seller sees as a result, and how each answer leads to a screen, is on Prequalification.
The Evaluation That Runs
Evaluation that runs has the hint The seller does not pick it: this one runs. Pick none and the seller cannot prequalify. It lists the published workflows of the Recommendation category. The choice is pinned by the workflow's alias, so publishing a new version of the same workflow keeps the portal working with no change here. See Publishing Workflows and, for the alias, Getting Started.
With Prequalify a customer on and no evaluation chosen, Save is blocked with Pick the evaluation that runs: without it the seller cannot prequalify.
The pickers on this card explain their own state. A saved choice that is no longer published shows as {name} (no longer available), with the hint What is selected is no longer published. Pick another one. When no evaluation is published at all, the hint reads No evaluation is published. Until there is one, the seller cannot prequalify. And when the list of workflows cannot be read, it says We could not read the catalog. Reload the page to try again.
Which Identity Fills Each Input
Once an evaluation is chosen, Which identity fills each input lists every input that evaluation asks for. For each one you choose a customer identity, such as a tax ID or a national ID, or The seller types it. The hint under the rows reads An input with no identity is typed by the seller. Leaving an input unmapped is the right choice for something that is not a document, such as a requested amount.
The mapping is what lets the portal prefill the form when the seller picks an existing customer: the identity you chose is the document the evaluation runs against. Identities marked as sensitive are not offered, because the portal never receives them. If the evaluation has no inputs, the section says This evaluation asks for no inputs. If your organization has no identities defined, or only sensitive ones, it says No identities are defined. Create one in the data models to be able to map. See Identities and Data Models.
Choosing a different evaluation clears the mapping, because its inputs are different. Choosing the same evaluation again keeps it.
Customer Search and Its Scope
Customer search in this step adds a customer search to the prequalification step, so the seller can pick an existing customer instead of typing their details. For an organization that has never saved the configuration, this switch starts on.
With the search on and no input mapped to an identity, the card warns: No evaluation input is mapped to an identity: picking a customer will prefill nothing and the seller types everything.
With the search on, Search scope offers two options:
| Option | What the seller reaches |
|---|---|
| Only the customers of their routes (default) | Only customers on the seller's own routes. |
| Every customer in the organization | Every customer in the organization, shown with a warning hint on the card. |
Organization-wide scope opens more than the search
With Every customer in the organization, the reach is not limited to the prequalification search. The seller's Customers list, its search and the customer detail also cover the whole organization, unless the seller narrows the list to one of their own routes, and the seller can prequalify and simulate for any of those customers. The distributor list for the branch number covers the whole organization too. Choose it only when every seller should be able to see every customer.
Search scope stays in effect when you turn Customer search in this step off. The selector is hidden, but a saved Every customer in the organization keeps the Customers list, its search, the customer detail and the distributor list open to the whole organization. To narrow the reach, turn the search back on, choose Only the customers of their routes and save.
See Customer Book for how the list behaves under each scope.
Answer Lists
Three lists hold the words your evaluation returns in its decision output:
- Which answers let the seller continue
- Which answers are a rejection
- Which answers need review
Type a value and press Enter, or just leave the field, to add it. The first list's field suggests APPROVED, then Enter; the other two suggest Type a value and press Enter (e.g. rechazado) and Type a value and press Enter (e.g. revision). Matching ignores case, accents and spaces at the start and end of the answer; spaces inside it count ("pre aprobado" does not match "preaprobado"). Each list takes up to 20 values of up to 60 characters, with no duplicates, and duplicates are also compared ignoring case and accents. A value that breaks one of these rules is not added, and the reason shows under the field: Each state takes up to 60 characters., You reached the maximum of 20 states. or That state is already on the list. The hint under the lists sums it up: These are the words your evaluation returns in decision. They decide which screen the seller sees and whether they can continue to the simulation. Write them as it emits them; case and accents do not matter.
An empty list falls back to built-in words:
| List | When it is empty |
|---|---|
| Continue | The standard values apply: pre-approved and approved, plus review. |
| Rejection | With these the seller sees “does not qualify”. Empty: “rechazado” and “no” are detected on their own. |
| Review | With these the seller sees “needs review” and can still continue. Empty: “revisión” is detected on its own. |
Fill the lists when your evaluation uses its own vocabulary. An answer the portal cannot classify is never treated as a rejection, but it is not treated as an approval either. The full rules are on Prequalification.
Approved Amount
Where the approved amount comes from has two options:
- The evaluation returns it (default). Below it, an optional field (shown empty with cupoAprobado as its example) takes the exact name your evaluation returns the amount under. When it is empty, or holds only spaces, the usual names are tried; the list is on Prequalification.
- No approved amount is used. No limit is read from the evaluation: the simulation opens with no suggested amount and no cap, and the seller types the amount to finance.
Switching away from The evaluation returns it clears the variable name.
Show approved amount is on by default. Turned off, the seller never sees the approved figure and types the amount in the simulation. The decision, the notices and the maximum term are unchanged.
Allow Continuing Anyway
Allow continuing anyway, with the hint With this on, a customer who does not qualify can still move to the operation., is on by default. With it on, a rejection does not end the sale: it travels with the saved simulation and is printed on its document. The exact rules, including how it combines with the answer lists, are on Prequalification.
Operation Settings
These settings sit under Build an operation. How the seller fills in the operation and builds the plan is on Operation Data and Payment Plan.
Branch Number
Branch number has two options. With The seller types it (default), the seller writes the branch by hand. With Picked from the distributor list, the seller chooses one of the distributors of their routes (of the whole organization when Search scope is Every customer in the organization), and that distributor's External ID is saved as the branch, as text, and carried to the simulation and its document. Distributors are created on Sales Routes and Sellers.
Product and Organization Rates
The seller must pick a product is on by default. Turning it off reveals the Your organization's rates block, with four percentage fields:
| Field | Placeholder |
|---|---|
| VAT on interest | 10.5 |
| VAT on refinancing | 21 |
| Origination fee | 1.5 |
| Default TNA | 10 |
A rate filled in here wins over the chosen product's own rate, field by field. An empty field lets the product answer, and when the product has nothing either, the built-in default applies. Rates are not negative, and zero is a valid rate. The block is only hidden when you turn the switch back on, not emptied, so values already saved there stay in effect. The full precedence is on Operation Data and Payment Plan.
Default TNA has the hint The value the portal prefills the TNA with; the seller can change it. Since it sits in the rates block, you can only edit it while The seller must pick a product is off.
Despite its name, this switch does not change what the seller does. The portal still asks for a product when your catalog has more than one, picks it automatically when there is only one, and cannot continue when there is none. Its only effect is to show the rates block.
Financed Origination Fees
Finance the origination fees is off by default. Turned on, the fees join the capital and are paid across the installments. Turned off, they are charged at signing.
Maximum Term
Where the maximum term comes from has four options:
| Option | Where the term comes from |
|---|---|
| From the credit product (default) | The chosen product's maximum term. |
| The evaluation returns it | The prequalification's output. An optional field (example plazoMaximo) names it; when it is empty, the usual names are tried (listed on Prequalification). |
| The seller types it | The seller writes it in the operation. |
| Set here | A whole-number field that appears under the selector (example 12): required, at least 1. |
A term set here caps both the portal and the simulations created in the Hub (see Own Financing in the Hub). The seller sees it but cannot change it.
With Set here, an empty or invalid number turns the field red, with It has to be a whole number of at least 1. under it, and Save is blocked with Type the maximum term in months: it is required with "Set here"., even while Build an operation is off. With any other source, a number left in that field is ignored.
Onboarding Settings
Also under Build an operation, Send the bot to the customer is on by default. Its hint explains the other position: Off, the operation ends at the summary: no bot or channel is required and the portal does not offer the send.
With sending on, two settings are required:
- Bot that greets the customer lists your published conversational flows. See Conversational Flows.
- How it is sent offers By email, with a link or By WhatsApp, with a QR.
With Build an operation on and either one missing, Save is blocked, with Pick the bot that greets the customer: without it there is nobody to send the onboarding to. or Pick how the bot is sent to the customer. When no bot is published, the hint reads No bot is published. Until there is one, the seller cannot send the onboarding. What the seller does with this, and what the customer receives, is on Customer Onboarding.
Simulation Actions
Simulation actions are workflows of the Action category that the seller can run on a saved simulation, on the deal linked to it, without typing anything. You choose up to five, in the order the seller will see them, with an optional label and whether each is available on every saved simulation or only on approved ones. Which workflows qualify and what the seller sees when one runs are on Simulation Actions.
Seller Access
Seller access sets how sellers sign in (an access link or a one-time code), which OTP channel and template are used, and how long a session lasts before the seller has to sign in again. The same section holds Route assignment, which decides whether a route has one seller or several. Sign-in and sessions are on Access and Sessions; routes, sellers and distributors are on Sales Routes and Sellers.
Branding
The Branding section has the hint How the seller sees the portal. The customer who opens the bot link does not see this.
Primary Color
Primary color is a color picker plus a hex field in #RRGGBB form; the # is optional when you paste a value. A button clears it, and a Preview shows a Continue button with the line This is how the portal's buttons look.
The portal derives its whole palette from this color, not only the buttons. The colors that carry an outcome do not follow it: the approved, rejected and review results keep fixed colors, and so do the approved, pending, rejected and expired status badges, so they read the same in every organization. The badge for a simulation that is waiting on the customer (onboarding sent, or approval in progress) follows your color. Leaving the field empty keeps the standard palette.
Buttons always use white text, so a light color shows the warning The portal always writes button labels in white: with this color they will be hard to read. Pick a darker one. It is only a warning and does not block Save. A value that is not a valid hex color shows That is not a valid hexadecimal color. Use the #RRGGBB format. under the field and blocks Save.
Document Footer
Document footer has the hint Institutional or legal text printed at the foot of the simulation PDF. Empty, the document has no footer. Not for customer data. It takes up to 2000 characters and 12 lines, with a counter. Going over blocks Save with The document footer exceeds 2000 characters or 12 lines. The footer is only printed; it never shows on screen.
There is no terms-and-conditions field on this card. The terms printed on the document come from the credit product (see Saved Simulations and History). The only document texts you set here are the footer and the logo.
Logo
Company logo accepts a PNG, JPG, GIF, WebP or SVG file of up to 5 MB. Unlike everything else on the card, the logo uploads, or is removed, immediately, without waiting for Save. The hint below it reads: The logo is published as a public file: anyone with the link can see it, and it is shown in the seller portal.
Uploading or removing the logo needs the configurations.write permission; without it, the card shows You do not have permission to change the logo. An upload shows Logo updated and a removal Logo removed. When one fails, the card shows the reason the server gave, or Could not upload the logo or Could not remove the logo when it gave none. Replacing or removing the logo deletes the previous public file, so any link to the old logo stops working.
It is one logo shared by the AltScore portals, so changing it here changes it everywhere it is used. If the portal cannot read it, it simply shows no logo.
Saving and Opening the Portal
The footer of the card has Open the portal and Save (Saving... while it works). Every Save writes the whole portal configuration exactly as the card shows it, including the settings under capabilities that are off.
When Save is blocked, the first blocking reason shows in red above the buttons, checked in this order: the session times (Check the session times.), the session window (The session lasts longer than the maximum.), nothing enabled, the color (Check the primary color.), the footer, a missing evaluation, a missing bot, a missing channel, the maximum term and the simulation actions. Fix that one and the next one, if any, takes its place. A successful save shows Settings saved. When sellers sign in with a code and no OTP template is chosen, it saves anyway but shows Saved, but without an OTP template sellers cannot sign in. Pick a template. instead. A failed save shows the reason the server gave, or The settings could not be saved when it gave none.
Open the portal opens your organization's portal sign-in page in a new tab. It generates no access link, so your sellers' live links keep working. It is disabled while there are unsaved changes, with the hint The portal shows the last saved version: save your changes before opening it. If your sellers sign in with an access link, the portal will ask for one, so you cannot get in from here; with code sign-in you reach the code form. See Access and Sessions.
Defaults
What applies when a setting has never been saved:
| Setting | Default |
|---|---|
| Capabilities, before the first save | Customers section only; no prequalification, no simulation |
| Evaluation that runs | None |
| Which identity fills each input | Empty: the seller types every input |
| Customer search in this step | On for an organization that never saved; off when a saved configuration lacks it |
| Search scope | Only the customers of their routes |
| The three answer lists | Empty: the built-in words apply |
| Where the approved amount comes from | The evaluation returns it, with the usual variable names |
| Show approved amount | On |
| Allow continuing anyway | On |
| Branch number | The seller types it |
| The seller must pick a product | On |
| Your organization's rates and Default TNA | Empty |
| Finance the origination fees | Off |
| Where the maximum term comes from | From the credit product |
| Send the bot to the customer | On |
| Bot that greets the customer and How it is sent | None |
| Simulation actions | None |
| Route assignment | One seller per route |
| Sign-in method | Access token |
| OTP channel | |
| OTP template | No template |
| Session length (minutes) | 45 |
| Maximum before signing in again (hours) | 12 |
| Primary color | Empty: the standard palette |
| Document footer | Empty: no footer |
Things to Know
Saving does not check that your choices still exist. The evaluation, the bot and the mapped identities can all be archived after you save. Nothing here stops that; the portal tells the seller what is missing when they try to use it, and this card marks the choice as no longer available the next time you open it. After archiving or unpublishing anything the portal uses, come back and check the card.
Changes reach sellers in two ways. What the portal checks on each request applies immediately: turning a capability off refuses it on the seller's next action, even mid-sale. What the portal shows (the menu and steps, the evaluation that runs, the answer lists, the identity mapping, the operation settings and the primary color) is read once when the seller opens the portal, so a seller who already has it open sees the change after reloading the page or opening it again. Nobody has to sign in again. Until that reload, a seller can still see a section or step that is now refused, so plan a change like that for a quiet time if sellers are in the middle of a sale.
Seller Portal
A mobile web app where your field sellers reach their customers, prequalify them and simulate own financing, without a password and with every rule set by you in the Hub.
Sales Routes and Sellers
How to group customers into sales routes, register the sellers who cover them and the distributors above them, so each seller's portal shows the right customers.