How GoldFinch ERP/WMS is architected on the Salesforce Platform — layers, components, communication, and where external systems connect.
SaaS Built on Salesforce No separate hosting required HTTPS/TLS
GoldFinch ERP/WMS is delivered as a SaaS application built natively on the Salesforce Platform. Core application logic and business data run entirely inside your organization's Salesforce org — there is no separate GoldFinch-hosted server, application tier, or database to stand up or maintain. Everything described below operates inside your Salesforce trust boundary.
Architecture diagram
Figure 1 — GoldFinch's layered architecture. All core layers run inside your Salesforce org; external systems connect only through scoped, governed integrations.
Layer-by-layer breakdown
1. Users & devices
People access GoldFinch through currently supported desktop browsers, the Salesforce mobile app, or approved scanners, tablets, and label/laser printers. Validate specific scanner and printer combinations against your production hardware before purchase or deployment.
2. Salesforce Experience layer
This is what users actually see and interact with: Lightning applications, mobile-enabled pages, and standard Salesforce reports and dashboards. Landing pages and navigation can be tailored per profile or permission set, so different roles (warehouse staff, procurement, volunteers) get a relevant home experience.
3. GoldFinch managed application layer
This is the packaged GoldFinch application itself — a managed AppExchange product, not custom-built software. It includes:
- Lightning Web Components (JavaScript, HTML, CSS) for the interactive screens
- Apex classes and triggers for transactional business logic
- Salesforce Flow and approval processes for declarative automation (e.g., PO approval thresholds)
- Scheduled and batch jobs for background processing (e.g., replenishment calculations)
Implementation is delivered through configuration and, where required, standard Salesforce customization tools — not ground-up custom development.
4. Salesforce platform & data layer
Salesforce objects and files store all business data. This layer also provides the security and sharing model (profiles, permission sets, roles), audit capabilities (Setup Audit Trail, Field History Tracking), and the governed API surface — REST, SOAP, Bulk API, Platform Events, and Apex callouts — that everything above and any external system uses to read or write data. No layer has raw database access.
5. Optional external systems
Financial systems, tax engines, payment processors, banking, EDI, shipping/routing tools, and BI platforms can connect through scoped, governed integration designs. See Integration Methods Overview for the specific protocols and tools available.
Communication & protocols
| Path | Protocol / Method |
| Browser and mobile traffic | HTTPS/TLS |
| Approved external integrations | Salesforce REST API, SOAP API, Bulk API, Platform Events, or Apex callouts — never raw database access |
Environments included
| Environment | Included? |
| Sandbox (test/training) | Yes, included with a GoldFinch subscription |
| Dev org (development) | Yes, included with a GoldFinch subscription |
| Not direct database replication. A Salesforce Full Sandbox is a point-in-time copy for testing — it is not a high-availability or disaster-recovery replica. For downstream analytics or replication, use Salesforce APIs, change events, scheduled exports, or a connected BI platform such as Microsoft Fabric or Data 360 (subject to licensing). |
Package vs. custom development
GoldFinch is a packaged, managed AppExchange application. This matters for architecture because it means:
- Upgrades are delivered as managed-package releases, not custom code merges
- Core functionality is configuration-driven (fields, record types, Flow) rather than requiring development for standard use cases
- Apex/LWC development is reserved for genuinely custom requirements, layered on top of the managed package
Multi-language & locale support
Multiple languages and locales are supported at the Salesforce platform level, and language/locale settings can be configured per individual user.
Known technical constraints
- No direct access to the underlying Salesforce database — all data access goes through reports, SOQL, APIs, exports, or approved connectors
- Standard Salesforce API, storage, and governor limits apply
- Not every desktop workflow is optimized for phone-sized screens
- Scanner and label-printer compatibility should be validated against production hardware before deployment
- Customer-specific automation, integrations, or third-party packages can affect performance and release compatibility
Comments
0 comments
Please sign in to leave a comment.