Fortmilo

Architecture & Security

Salesforce-native, bounded and explainable.

Security Observatory separates experience, orchestration, collection, evidence and governance so each documented trust boundary stays visible.

Diagram 1

Runtime architecture

Server-side collection and retention, browser-side CSV preparation and local download

Security Observatory runtime architecture The review surface invokes Apex orchestration, which invokes read-only scanner families. Scanner results are sanitised and normalised before retained Salesforce evidence is made available for review, drill-down and comparison. Collection and retention occur inside the subscriber Salesforce organisation. The LWC prepares the allow-listed CSV in the authenticated browser session; downloading it creates a file outside Salesforce. AUTHENTICATED BROWSER SESSION SUBSCRIBER SALESFORCE ORGANISATION LWC reviewsurfaceApex servicesand orchestrationRead-onlyscanner familiesSanitised andnormalised resultRetained SalesforceevidenceReview, drill-downand comparisonAllow-listed CSVpreparationDownloadedsanitised CSV invokesinvokesreturns resultretains evidencereview relationshipLWC PREPARES CSVUSER-INITIATED DOWNLOAD

Diagram key: Solid arrows show execution or evidence/result relationships, as labelled. Dashed outlines show trust or ownership boundaries.

What happensThe review surface invokes server-side Apex orchestration and scanner families; sanitised results are retained in Salesforce and returned to the authenticated browser.
Security propertyCollection and retention occur inside the subscriber Salesforce organisation. The LWC prepares the allow-listed CSV in the authenticated browser session; downloading it creates a file outside Salesforce.
Deliberate boundaryServer-side collection and retention, authenticated-browser execution and the downloaded local file remain three separate boundaries.

Licence-assignment retention boundary

Bounded evidence, not an organisation limit

At the Everything evidence detail level, retained assignment evidence is bounded to 1,000 rows for each of Package Licences, Permission Set Licences and Salesforce User Licences. The 3,000-row maximum is theoretical; safe capture may be lower than expected or zero when Salesforce transaction/DML headroom is exhausted. Zero captured must not be inferred as zero assignments or shown as Complete; an unknown expected count remains unknown. Incomplete is a separate licence-assignment capture status, not a rendered evidence state, and capped retained counts are not exact organisation totals.

Diagram 2

Subscriber authentication and trust boundary

Subscriber-owned OAuth configuration for the Tooling API self-callout

Subscriber authentication boundary Packaged SOQL scanners retain evidence without the Tooling self-callout. Tooling-backed scanners use a Named Credential and External Credential principal for an authenticated call to the subscriber Salesforce Tooling API. OAuth provider and client registration are subscriber configuration. If required Tooling evidence cannot be obtained, the scanner reports it as unavailable with a bounded cause and next action; setup preflight may prevent the callout from being attempted. PACKAGED CORESUBSCRIBER-OWNED SETUPTRUST / OWNERSHIP BOUNDARY Core SOQL-backedscannersTooling-backedscanner familySanitised retained result / evidenceNo credential values retainedTOOLING EVIDENCE UNAVAILABLERequired read could not completeBounded cause + safe next actionSetup preflight may skip calloutNamed Credentialcallout definitionSubscriber SalesforceTooling API endpointExternal CredentialOAuth configurationExternal Credentialprincipal / accessExternal AuthIdentity ProviderExternal Client AppOAuth client registration OAuth self-calloutendpointuses credentialprincipal accessreferences providermissing / blocked / insufficient
What happensCore SOQL-backed evidence does not require the Tooling setup; the Tooling-backed path uses the subscriber-authenticated Named Credential self-callout.
Security propertyThe subscriber owns the OAuth registration, provider configuration, credential principal and callout endpoint; no credential values are retained as review evidence.
Deliberate boundaryBecause the scanner attempted the source and could not complete the read, the rendered state is Unavailable, not Not assessed. It carries a bounded cause and safe next action.

Diagram 3 · ArchiMate application and technology view

Why the Observatory uses the Tooling API

Salesforce security evidence lives in different surfaces. The Observatory uses ordinary SOQL for records it can query directly, and the Tooling API for selected metadata-oriented reads.

Two read paths · one sanitised evidence model · all scanning stays in the subscriber org

ArchiMate view: why and how Security Observatory uses Tooling API Inside the subscriber Salesforce organisation, Apex scanners use ordinary SOQL for directly queryable security records. Selected metadata scanners use a subscriber-owned Named Credential and OAuth principal to make read-only Tooling API queries for setup metadata such as Health Check risks, certificates, Named Credentials and External Credentials. Both paths pass through sanitisation and evidence classification; eligible results are retained as scan evidence for authorised review. Automatic scan evidence stays inside the subscriber organisation. SUBSCRIBER SALESFORCE ORGANISATION · TRUST BOUNDARY BUSINESS BUSINESS ROLESecurity reviewer / admin BUSINESS PROCESSReview evidence · decide performs APPLICATION APPLICATION COMPONENTApex scanorchestration APPLICATION FUNCTION · STANDARD PATHApex + SOQL scannersDirectly queryable org records APPLICATION FUNCTION · TOOLING PATHMetadata scannersUse Tooling when this query surface fits APPLICATION SERVICEAuthenticated calloutNamed Credential + principal APPLICATION FUNCTIONSanitise + classifySource · coverage · status DATA OBJECTSScan · finding · assetRetained in Salesforce triggers reads with SOQL uses returns scanner evidence normalises TECHNOLOGY TECHNOLOGY SERVICESalesforce records · SOQLUsers · permissions · other queried evidence TECHNOLOGY SERVICETooling API · RESTSubscriber org · query endpoint TOOLING QUERY SUBJECTSHealth Check · CertificateNamed / External Credential calls queries metadata rows return to scanner serves review

ArchiMate key: Labels identify element types; arrows show the named relationships. The dashed outline marks the subscriber organisation boundary. Tooling API provides selected metadata query paths alongside standard SOQL. Salesforce: When to Use Tooling API.

Why Tooling API?Selected setup and configuration evidence is exposed through metadata-oriented Tooling API objects. This is the query surface used by those scanners.
Why two paths?Standard SOQL reads directly queryable records; selected metadata scanners use Tooling API.
What crosses the boundary?Automatic scanning sends no evidence to Fortmilo. Sanitised review evidence remains in the subscriber org. Failed Tooling setup cannot become a confirmed zero.

Diagram 4

Evidence lifecycle and sanitisation

Prohibited sensitive categories are removed before retained review evidence

Evidence lifecycle and sanitisation Read-only scanner output passes through filtering and normalisation before bounded evidence is retained for review. The reviewed retention boundary excludes tokens, session identifiers, secrets and certificate bodies. Raw IP values are omitted or redacted, with exact retained-data shape validated per environment. Read-only scannerresultSensitive-valuefilterNormalisedevidence modelRetained Salesforceevidence objects Source + provenanceProhibited categories filteredState + coverage + reasonReview and comparison NEVER RETAIN FOR REVIEWTokens · session IDs · secrets · certificate bodies
What happensScanner output is filtered, normalised and retained with provenance and limitation context.
Security propertyThe reviewed retained-evidence boundary excludes tokens, session identifiers, secrets and certificate bodies.
Deliberate boundaryRaw IP values are omitted or redacted; exact retained-data and export shape remains environment-specific rather than being inferred from the diagram.

Diagram 5

Assessment, availability and observed zero

A successful zero is reached only after usable evidence was obtained and no matching records were observed

Canonical evidence-state decision path The decision first asks whether assessment was attempted. If not, the rendered state is Not assessed for the run or assessed scope. If assessment was attempted, the next decision asks whether usable evidence was obtained. A failed required source or read, including a Tooling setup preflight that prevents the HTTP call, produces Unavailable with a bounded cause and safe next action. Only after usable evidence is obtained does the flow ask whether matching records were observed. Matching records produce a contextual metric or finding label; no matching records produce None found. Composite evidence may retain a Partial usable count while identifying each missing portion separately as Not assessed, Unavailable, Not retained at this evidence level or Not captured. Not applicable covers questions outside the assessed context; Incomplete remains a separate licence-assignment capture status. SOURCE / FAMILYCONTEXT Was assessmentattempted? NOT ASSESSEDNot assessed for run or scope Was usable evidenceobtained? UNAVAILABLERequired evidence not obtained BOUNDED CAUSE+ SAFE NEXTACTION Matching recordsobserved? CONTEXTUALRESULTMetric or finding label NONE FOUNDSuccessful assessed zero COMPOSITE EVIDENCE Retain any usable count as Partial; identify each missing portion separately: Unavailable: attempted source unusable · Not assessed: work not performed / outside scope Not retained: intentional level omission · Not captured: product does not capture Incomplete: separate licence-assignment capture status NOYESYESNOYESNO
What happensThe path separates non-assessment from attempted evidence collection, then separates source failure from a successful assessment with or without matching records.
Security propertyAn attempted assessment with unavailable required evidence is Unavailable even if preflight prevents the HTTP call. None found requires usable evidence and no matching records.
Deliberate boundaryEach missing portion remains separately Not assessed, Unavailable, Not retained at this evidence level or Not captured. Not applicable is used when a question does not apply; Incomplete is a separate licence-assignment capture status.

Technical whitepaper

Evidence Semantics and Scanner Orchestration

The explanation of the evidence semantics, consistent scanner plan and bounded licence-assignment retention model behind Security Observatory.

Read the technical whitepaper