Sales Force Automation

The register where a sales team records leads — a named contact at an organisation who might buy — files each under a project, a source, a stage, a type and a rating, and converts the ones that mature into deals; nothing in it is an accounting document, and a lead becomes an invoice only when a person re-keys it. Before you put a team on it, check which build you have: the bundle a tenant installs is a 2022 build, and several menus and fields in the source are not in it; every lead and deal needs a project, and the only screen that creates one has no menu entry. Converting a lead marks nothing on the lead, so pressing the button twice makes two deals.

Overview

Sales Force Automation is the register where a sales team records leads — a named contact at an organisation who might buy — files each lead under a project, a source, a stage, a type and a rating, and converts the ones that mature into deals. Around that sit a dashboard, the organisation register the leads point at, a CSV lead import and a set of qualification questionnaires. Nothing in it is an accounting document: a lead never becomes an invoice by itself, and the applet posts no journal and moves no stock.

Read the next two sections before you put a sales team on this. Which build a tenant installs is not what this page said until 2026-09-19. Everything below is read from source at the commits in sources_read_at:, not from anybody’s experience of using it, and the places where that distinction matters are marked.

Which build you get

Two repositories carry the name Sales Force Automation, and the registry row installs the older one, which is the build this page documents.

The SFA row in the applet registry (ACTIVE, registered 2022-03-16) points at …/akaun-platform/sfa/prod/sfa-elements.js. Only the older repository builds a file of that name — its production build script emits sfa-elements.js and its publish script copies it to exactly that prefix. The rebuild’s production script targets the same prefix, but its build emits sfa-applet-elements.js, a file name no registry row references. Fetching the object the row points at settles it: the route prefix inside is the older build’s applets/akaun/sfa, it carries that build’s Closed Won and Closed Lost strings, and it contains no occurrence of the rebuild’s route prefix.

A rebuild was started in late 2025 in a second repository. It has one commit, nothing has moved since January 2026, and no registry row installs it, so it is not described here. If you have seen this page describe a three-menu applet with no lead edit screen whose Organization menu opened stock-reservation screens, that was the rebuild, and leading with it was wrong.

Where it fits

Two organisation registers. The platform keeps an SFA organisation list and a CRM organisation register. This applet’s Organization menu, a lead’s organisation and a deal’s organisation all use the CRM one. If you are writing an integration, use the CRM organisations — the SFA list is not what these screens read.

Screens and menus

Route prefix applets/akaun/sfa; the applet opens on Dashboard.

Screens you can reach only by typing the URL

Eleven of the fifteen routed settings screens have no menu entry, and two of them are the ones you need first.

Two consequences worth knowing. There is no rating-settings route at all — the commented-out menu entry of that name points at a path that was never defined, so uncommenting it would 404; ratings come from Project Settings or Lead Settings. And opening Settings lands you on a screen the menu does not list: the empty settings path redirects to Client-Side Permissions, with nothing highlighted in the side menu.

Closed Won and Closed Lost are screens without a door, and they show made-up data. Both routes (closed-won, closed-lost) are in the installed bundle; both menu entries and both menu icons are commented out, no screen links to them, and the Deals editor has no close action — so the only way in is to type the URL. What you find is three hard-coded rows with invented titles and contact names, a create form whose Save reads three form controls that the form does not have, and an edit form whose Save has an empty body. They are unconverted copies of a contact-centre template-message screen. They are not a report of your closed deals, and there is no close action anywhere in the applet: a deal is “closed” only if you named one of your own deal stages that way.

Personalization offers Field Settings and Default Selection; only personal-default-selection and sidebar are routed under it, so the Field Settings entry there is a dead link.

No screenshots are published for this applet: none exist under static/images/, and none was captured for this page.

Configuration

Before you can use it

• A project, and then everything under it. On the lead form, Lead Type, Lead Source, Lead Stage and Lead Rating are all fetched for the project you chose. Until that project has rows of its own, those four drop-downs are empty and the form cannot be saved. Create the project and its four registers on Project Settings, or the registers on Lead Settings / Deal Settings — none of which has a menu entry.
• At least one lead rating, because the rating carries the probability, and there is no other way to put a number in the Probability box.
• Organisations, from the Organization menu or the lead form’s Select Organization picker.
• Qualification criteria and criteria sets, if you intend to use the Qualification tab.
• Nothing else. No GL code, no document numbering, no tax code, no cashbook, no company or branch, because the applet writes no document and its rows carry no company, branch or location.

Applet settings

For completeness, the keys involved. Default Selection and its personal twin write DEFAULT_BRANCH and DEFAULT_LOCATION into the applet’s APPLET_SETTINGS extension row. Application Settings (repository only) writes a code-format key, a running-number-method key and the category-group list into the same row, through the shared session effect that merges rather than replaces — and of its three keys only the category-group list has a control on the screen, so the other two are saved at whatever was loaded or at their hard-coded defaults.

On the screen and doing nothing

• DEFAULT_BRANCH, DEFAULT_LOCATION — shown and saved by Default Selection and by its personal twin, and used by nothing: no lead, deal, organisation or import carries a branch or a location in the first place.
• The code-format key (repository only) — the Application Settings form writes it under one name while the applet expects another (the sales-lead code format). A stored value under the expected name is never loaded into the form, and the name the form saves is one the screens never use. Whether lead codes honour either spelling is not established — do not rely on this setting.

Who can change what

This applet has no client-side permissions and asks for none. Nothing on any screen is hidden or shown by a grant.

Server-side is the only permission surface that exists here, and it is thorough. Every endpoint in the SFA package is an authenticated tenant endpoint; there is no anonymous or public lookup anywhere in it. Each table has its own seven-verb family in TntSfaPermissions (…_OWNER, _ADMIN, _MEMBER, _CREATE, _UPDATE, _DELETE, _READ). Two of those families behave unexpectedly:

• API_TNT_DM_SFA_SALES_LEAD_EVENT_* gates nothing on its own. No controller exposes the event table; events are only ever written and read nested inside a lead.
• The import’s background jobs read leads with the file-upload-line permission, not the lead permission — so granting someone the right to upload a file is granting the right to have leads created by a job that never checks the lead permission.

Settings in other applets that control this applet

None.

Fields

The lead form

Create and Edit are two different forms over the same row, and they do not agree. Create takes a title, the organisation and project the lead belongs to, the contact’s name, work phone and work e-mail, a contact type, the four classifications, a probability, a priority, remarks and four dates — target start, target end, last follow-up and next follow-up. Edit adds Assignee and Reporter drawn from the tenant’s users, shows Created By / Created Date / Updated By / Updated Date read-only, moves the four dates onto a Planning tab, and adds the Events, Qualification, Contacts, Attachment and Lead-To-Deal tabs.

The rows below are the ones that behave in a way the screen does not show.

Saving does not wait for the answer. Create dispatches the POST and immediately clears the form; Edit dispatches the PUT and immediately closes the editor. Both then show a green toast on success and a red one on failure — over a form that has already gone. DELETE LEAD asks nothing: there is no confirmation dialog.

The lead listing

Columns are Org Name, Contact Name, Type, Lead Source, Probability, Priority, Stage, Date Created and Date Updated, newest-updated first.

Four of those columns are resolved in your browser, and fall back to blank. Org Name, Type, Lead Source and Stage are stored as identifiers; the grid looks each one up in a list it fetched separately and prints an empty string when it does not find it. So an empty Stage cell means either “this lead has no stage” or “the list this screen loaded did not include it”, and the screen cannot tell you which. The lookup lists are capped, so the ceiling is real rather than theoretical. If a column looks emptier than you expect, open the lead — the edit form reads its values from the row itself.

The deal form

Details takes Title, Project, Organization, Deal Type, Deal Source, Deal Stage, Contact Name, Work Phone, Work Email, Deal Rating, Probability, Priority and Remarks; Planning takes the same four dates as a lead. Three things the screen does not tell you:

• Probability is read-only here too, filled only by the Deal Rating, and choosing a Project blanks it — on both the create and the edit form.
• Reporter and Assignee are hard-coded to you with no control anywhere. Every deal is self-assigned, and nothing on any screen can reassign one.
• SAVE is disabled until you change something, and it is only present on the Details and Planning tabs. On Qualification, Account, Worklog, Attachment, Contact, Line Items and Events there is no save button at all. DELETE has no confirmation.

Unlike the lead and organisation editors, the deal editor rebuilds its payload from the loaded row, so a deal save never blanks a column it did not render.

The organisation form

Two more on the same pair of screens. On Create, seven labelled inputs — Entity type, Industry, Client Group, the Details-tab Country, Operating Country, No of Employee and Revenue — are collected and never sent; only the Address tab’s country reaches the row. And the Address tab still listens to the last organisation you selected, and is not cleared when you navigate, so opening Create straight after editing an organisation pre-fills the new one with the previous one’s address. The State drop-down on that tab is required and is permanently empty, because the code reads a states property off the array of states rather than the array itself.

Lifecycle and effects

No server document type, no journal, no stock. There is no SFA, SALES_LEAD, LEAD, DEAL or OPPORTUNITY entry in the document-type or journal-posting handlers. A lead is a master-data row under sfa/sales-leads (POST, PUT, DELETE /{guid}, GET, GET /{guid}, GET /query, GET /listing/query), and a deal is the same shape under sfa/deals.

Converting a lead into a deal

The Lead-To-Deal tab on a lead’s edit screen is the conversion, and it happens entirely in your browser. Nothing on the server converts a lead: deals can only be created, edited and deleted, the server never links a deal to its lead on its own, and the only things the server raises from a lead are a contact and an outbound task. What the tab does is build a deal from the lead and POST it:

• It copies contact name, title, description, probability, priority, e-mail, phone, organisation, project, source, stage, type and rating, and sets the deal’s lead reference — which the backend does validate, rejecting a deal whose lead does not exist or is deleted.
• It appends "- this was converted from lead guid # …" to the deal’s description. That sentence is the only human-readable trace of the conversion.
• The Title box on that tab is required and its value is thrown away — the deal takes the lead’s title.
• Nothing marks the lead as converted. No status change, no lead event, no guard. Press the button twice and you have two deals; the lead’s stage is whatever it already was, and no listing anywhere distinguishes a converted lead from an untouched one. The dashboard’s Lead converted to Deal tile counts from the deal side, by looking for deals that carry a lead reference.

The three contact registers

A lead can reach three different “contact” ideas, and none of them knows about the others:

• The lead’s Contacts tab creates a contact-centre contact and links it to the lead. That is the register the Unified Contact Center works in.
• AB Contacts and Address Book (repository only) are the applet’s own separate contact list.
• The Customer picker inside the lead reaches the customer master.

A person entered in one is invisible to the other two, and nothing de-duplicates across them. There is no uniqueness rule on a lead’s title, e-mail or phone either, so the same person can be entered as many times as you like.

The dashboard, and what its numbers really are

Five tiles and five charts, filtered by project and by a date range that is applied to the record’s creation date — not to any target or follow-up date on the lead or deal. The default range when you arrive is the last 30 days.

The last three are computed in your browser over one page of results, so on a busy tenant they stop counting at the page size rather than reporting a total. Every tile also shows a trend arrow and a percentage; the arrow and the 0% are hard-coded in all five and are not calculated from anything.

Of the five charts, Leads & Deals by Project zeroes the lead bar for a project that has leads but no deals, and the two deal pies — by source and by stage — are labelled “Lead” in their legend. Their name lookups are fired without being awaited, so a slow lookup leaves every slice labelled undefined. Charts, like the tiles, aggregate over one page.

The dashboard has no Notifications tab and no Sessions tab. Both exist only as commented-out markup, along with an Orders card, an Active Task list and an Active Campaigns card, none of which renders.

The CSV lead import

Upload posts to sfa/sales-lead-file-uploads/{type} as multipart with an options block; the type is hard-coded to the sales-lead one by the screen, and the server accepts no other.

The file must have exactly nineteen columns, named exactly these, in any order, case-insensitively, with the first row as the header:

PHONE_NUMBER, EMAIL, FIRST_NAME, LAST_NAME, PROBABILITY, PRIORITY, DOB, GENDER, NATIONALITY, ETHNICITY, LANGUAGE_CODE, TITLE, REGION_CODE, NAME, DESCRIPTION, SOURCE_CODE, STAGE_CODE, TYPE_CODE, ORGANIZATION_CODE

The check is on the count as well as the names, so an extra column fails the file — including one created by a trailing comma. That is stricter than the platform’s other file imports, which tolerate extra columns. Values are trimmed and a byte-order mark is tolerated.

Four background jobs then run, each queued by the one before it: the file processor reads the CSV and writes one row per line; the line processor, only if you ticked “create sales lead”, queues the creator; the creator builds and saves the lead and writes DONE or FAILED back onto the line, then queues the contact job and/or the outbound-task job; those two create a contact from the lead and an outbound task in the contact centre.

Six cautions, and you will meet most of them before you meet a successful import:

• The Details tab cannot be completed and does not matter. Its one control, a Project picker, is permanently empty — the function that fills it is commented out — and behind the placeholder it is built to query contact-centre agents rather than projects. The Project and File Type boxes are both marked required and neither value is sent; the ADD button has no disabled binding, so the required marks block nothing. The File Type list offers csv, json and tsv, and only .csv is accepted.
• Answering “no” to “Do you want to create Sales Lead?” still reveals the follow-up questions, and ticking them has no effect, because the handler tests the change event object rather than its value.
• The import header’s status is written from the boxes you ticked, not from what happened. The four per-stage status columns are set to DONE the moment the CSV finishes parsing — before a single downstream job has run — purely because you asked for that step, and they are never written again. A file whose every row fails still reads DONE.
• The screen will not show you why a row failed. A rejected row is recorded, with its error message, but the import’s line listing has no error-message column and no data column: a failed row looks like a row with unprocessed statuses and no explanation. A failure inside the file processor itself is caught and logged, so the queue records the job as successful. A rejected upload shows nothing at all, not even a toast, because the upload call has no error handler.
• Every uploaded file is stored under the name file. The code saves the multipart part name rather than the filename, and the part is called file for every upload. Tell two imports apart by their date, not their name.
• Re-driving does not do what it looks like. The per-line “create sales lead” endpoint hard-codes the contact and outbound-task options off, and decides a line is already done by checking whether a lead identifier was written rather than the line’s status. The import retry, which re-queues every failed import in the tenant, always reports “SUCCESSFULLY ADDED 0 JOB IN THE QUEUE” — the count it prints comes from the list of headers that failed to enqueue, inside the branch where that list is empty.

Three details of the lead the import builds that no screen shows: the contact it creates is looked up against a hard-coded source code and is created without a source, and without an error, if your tenant has no matching source row; the contact’s code and its name are both the contact name followed by the phone number or e-mail; and if a lead has both a phone and an e-mail the job creates two contacts, outside a transaction, so a failure on the second leaves the first behind while the line’s status reads FAILED.

The jobs behind an import

Five background jobs do the import’s work — reading the file, working each line, creating the lead, creating its contact and raising the outbound task. All five start when a file is uploaded, so none of them needs a schedule: there is nothing to set up in the Scheduler applet, and until somebody uploads a file none of them has anything to do.

What it will not do

• It will not stop you referring to something that is not there. Seven checks on a lead — project, organisation, rating, source, type, stage and file — are written so that they can never fail. An API caller can put any identifier into any of them and the row saves. The screens only ever offer real values, so this bites integrations, not people.
• It will not reliably stop a duplicate code on edit. Creating a project, source, stage, type or rating with a code that already exists is refused. Changing one to a code that already exists runs a check whose answer depends on which row the database returns first, so it sometimes passes. And codes are unique across the whole tenant, not per project, even though those tables carry a project.
• It will not validate the company on a lead. That column has a validator, in a class the backend references nowhere, so nothing checks it on any live path. The column is still filterable.
• It will not tell you a lead became a deal, or stop you converting one twice.
• It will not roll back a half-written lead, because the create path is not in a transaction.
• It has no close-won or close-lost action, and its Closed Won and Closed Lost screens show invented rows.
• It does not do pipeline reporting. The dashboard counts by project, source and stage; there is no forecast, no weighted value, no ageing and no won/lost rate, because a stage carries no meaning beyond its name.
• Settings › Product Services does not manage products or services. It is an unconverted copy of a contact-centre template-message screen and it reads and writes message templates.

Related applets

• Customer Maintenance — a lead is not a customer. Converting one means creating the customer there by hand; the lead form embeds the customer picker and create form for exactly that.
• Entity Maintenance — the lead header carries an entity reference, and no screen in either build sets it.
• Unified Contact Center — the only consumer of a lead: the CSV import can raise an outbound task per imported row, and a lead’s Contacts tab writes into the contact centre’s own contact register.
• Commission Scheme — owns the sales groups that share the sfa backend package.

Troubleshooting

Related documentation

• Digital CRM module
• Customer Maintenance
• Unified Contact Center