Sales Force Automation

Overview

Sales Force Automation (SFA) is the register where a sales team records leads — a named contact at an organisation who might buy — and files each lead under a project, a source, a stage and a type so the pipeline can be listed and filtered. It also keeps an address book of contacts (people, with job position, e-mail, phone and address) that is separate from the customer master. 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.

Two builds carry the name “Sales Force Automation”. The registry row is SFA (created 2022-03-16). The build documented on this page is the v2 rebuild (blg-applet-wavelet-sfa-applet-v2, route prefix applet/tnt/wavelet/erp/sfa-applet), which at commit bcd876a has three menus — Leads, AB Contacts, Organization — and four settings registers. The older build (blg-applets-sfa, route prefix applets/akaun/sfa, 3,577 commits from 2019-06 to 2025-11) has a Dashboard, Deals with Closed Won / Closed Lost lists, a CSV lead import, qualification criteria and lead-rating settings that v2 does not yet have. The SFA row installs the older build (see the note above). Where the two builds differ, this page says so.

Where it fits

Screens and menus

Route prefix applet/tnt/wavelet/erp/sfa-applet; the applet opens on Leads.

The older build (blg-applets-sfa) adds: Dashboard (lead and deal counts by project, source and stage, filtered by project and date range; Notifications and Sessions tabs), Deals with Closed Won and Closed Lost listings (a deal carries organisation, project, deal source / stage / type / rating, contact, description and duration; closing a deal fills in a template message), Import (a CSV of leads, tab Upload then Details), Address Book, and settings for Qualification Criteria and Qualification Criteria Sets, Product Services (template messages), Lead Settings (ratings with a probability, sources, stages, types) and Deal Settings.

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

Configuration

Before you can use it

• Projects, sources, stages, types — the lead form’s Project, Lead Type and Lead Stage drop-downs are required, and they are empty until the four settings registers below have rows. Create at least one of each before the first lead.
• Organisations — the Organization drop-down on the lead form is required and lists bl_crm_organization_hdr rows. In v2 the only way to create one is the Select Organization picker inside the lead form; the “Organization” menu does not manage them.
• Lead ratings — the Lead Rating drop-down reads bl_sfa_rating_hdr filtered by the chosen project. v2 has no screen to create ratings; they come from the older build’s Lead Settings or the API.
• Company, branch, location — only needed for the copied stock-reservation screens, which take them from the Default Selection settings; see Organization.
• Permissions — the applet loads the client-side permission codes attached to the user’s teams for this applet at start-up (app.component.ts); the permission listings under Settings are the shared platform screens.

Applet settings

Settings live in the applet-local Default Selection screen (tenant-wide, saved through saveMasterSettingsInit) and its personal twin under Personalization (savePersonalSettingsInit). Field Settings is the shared FieldConfigurationComponent from blg-shared-utilities; the applet’s own settings-container/field-configuration component exists but is not routed. Anyone with access to the Settings menu can change the tenant-wide values.

The settings model (applet-settings.model.ts) also declares the full sales-document family (INCLUDE_*, ENABLE_*, HIDE_UNIT_PRICE_*, PRINTABLE, custom-status toggles) copied from the document-applet template. None of those keys is rendered by any settings screen in this applet and none is read; they are not documented as settings.

Keys read at runtime without a settings screen of their own: DEFAULT_TOGGLE_COLUMN (SINGLE / DOUBLE), DEFAULT_ORIENTATION and VERTICAL_ORIENTATION — personal layout preferences written by the grid-toggle control on each settings listing and read back by the Projects / SFA Source / SFA Stage / SFA Type containers to decide one- or two-column layout.

The four settings registers

Each register is a listing (Code, Name, Status, Created Date, Modified Date) with a create and an edit form of three fields — Code, Name, Description — none of which is required by the form. The backend rejects a duplicate code on create and on update (SFA_PROJECT_HDR_OBJECT_CODE_ALREADY_EXISTS, SFA_SOURCE_HDR_OBJECT_CODE_ALREADY_EXISTS, SFA_STAGE_HDR_OBJECT_CODE_ALREADY_EXISTS, SFA_TYPE_HDR_OBJECT_CODE_ALREADY_EXISTS).

Document behaviour settings

Not applicable — the applet has no document type (see Lifecycle and effects).

Settings in other applets that control this applet

No exposed control found (routes and settings components checked at commit bcd876a; the copied stock-reservation screens read the printable-format key STOCK_RESERVATION_APPLET_EXT_CODE_PRINTABLE_FORMAT_GUID_STOCK_RESERVATION, which belongs to the Stock Reservation applet).

Feature visibility / permissions

Feature Visibility and Webhook under Settings are the shared platform components; the applet defines no feature-visibility key and no applet-specific client-side permission constant of its own (grep of the v2 source for perm_code and upper-case constants at bcd876a finds only the generic loader in app.component.ts). Server-side, every SFA endpoint is gated by the API_TNT_DM_SFA_*_READ / _WRITE permissions of the TntSfaPermissions enum. No client-side permission definitions are registered for this applet (0 rows in bl_applet_client_side_perm_dfn for SFA, queried 2026-09-15) — the registry and both builds agree.

Fields

Lead — Create (tab Details)

Save (POST sfa/sales-leads) also writes one bl_sfa_sales_lead_event row with event_code = SALES_LEAD_CREATED and sets both reporter and assignee to the current user. The table has columns the form never touches — firstname, lastname, dob, gender, nationality, company_name, contact_hdr_guid, entity_hdr_guid, email_optp — that the older build’s import fills.

AB Contact — Edit (created as a temporary row first)

Listing cards show Name, Type, Job Description, Email, Phone, Status.

Stock reservation (Organization menu)

Listing columns: Doc No, Item Name, Branch, Location, UOM, Reserved Qty, Status. The forms are the Stock Reservation applet’s and are documented on its page.

Lifecycle and effects

No server document type, no journal, no stock. ServerDocTypes, GenericDocumentTypeHandler and JournalPostingTypeHandler contain no SFA, SALES_LEAD, LEAD, DEAL or OPPORTUNITY entry (grep of blg-akaun-platform-java at 45edc03526). A lead is a master-data row under sfa/sales-leads (POST, PUT, DELETE /{guid}, GET, GET /query, GET /listing/query), validated by SfaSalesLeadHdrDataConsistencyObject: guid, created/updated subject, dates, status and revision must be present; there is no uniqueness rule on title, e-mail or phone, so the same person can be entered as many leads.

VOID does not exist for these rows; a lead is deleted or left with whatever status the client wrote.

Related applets

• Customer Maintenance — a lead is not a customer; converting one means creating the customer there by hand. The copied stock-reservation screens embed the customer picker and create form.
• Entity Maintenance — bl_sfa_sales_lead_hdr.entity_hdr_guid exists for a link to an entity; no v2 screen sets it.
• Commission Scheme — owns the sales groups that share the sfa backend package.
• Unified Contact Center — the only consumer of a lead: the older build’s import can raise an outbound task per imported lead.
• Stock Reservation — the screens behind v2’s Organization menu.

Troubleshooting

Related documentation

• Digital CRM module
• Customer Maintenance
• Unified Contact Center