Custom Salesforce Data Applications

A executive asks a simple question: what happens to next quarter if this pipeline slips? Salesforce holds the data, but the answer passes through an extract job, a warehouse, a planning backend, and a BI tool. When one link lags or breaks, people retreat to spreadsheets and decisions rest on numbers nobody fully trusts. The business pays twice, in licenses and in the engineering time spent keeping the boundaries between products working.

How Harper turns Salesforce data into one planning application

Salesforce stays the system of record. The application uses a read-only Salesforce connection: scheduled and manual syncs bring operational data into Harper, while selected calculations and authorized connector tools can issue live read-only queries. Nothing writes back. Inside Harper Fabric, the web UI, HTTP API, planning logic, data, scheduled jobs, snapshots, audit trail, access control, and Q&A run as one application.

This is an application, not just a dashboard. Reports, forecasts, scenario analysis, and operational workflows share one data store and one codebase. A changed assumption is saved in Harper, recalculated by the application and returned to the interface through its HTTP API.

Salesforce remains a one-way, read-only boundary. Google provides identity while Harper owns sessions, role mapping, and authorization. The in-app Q&A feature calls Anthropic, and Claude.ai can access the same operating model through a separate read-only MCP endpoint.

Alternatively, assemble the stack from separate products

One common assembled approach extracts Salesforce data with an integration tool and loads it into a database or data warehouse. An application backend contains the planning logic, a scheduler triggers jobs, and a BI and planning interface presents reports and captures inputs. Identity, an API gateway, hosting, deployment, monitoring and any AI or connector services surround it. The exact services vary by team; the point is not that every stack uses every box, but that each boundary must be integrated and operated. At best, it's a huge headache to maintain. At worst, it breaks.

Where the boundaries add work

Every handoff is a place for schedules to drift, schemas to change, and permissions to diverge. A late extract means the BI report and the planning backend show different numbers. Each product adds its own license, upgrade cycle, and failure mode, and someone must trace problems across all of them. Shared correctness needs exist in any design, but here they are spread over many owners. Harper reduces how many boundaries there are.

Why Harper matters

• Fewer products to license and connect. The ETL target, backend, scheduler, cache, gateway, and hosting collapse into one Fabric application boundary. The direction is fewer contracts and fewer integrations, though cost depends on your current stack.
• Planning beside the data. Forecasts and scenarios run where the synced data lives, so reports and calculations draw on one copy instead of several.
• A safer source of record. The sync only reads from Salesforce, so the application cannot change what Salesforce holds.
• An application shaped to your business. Because the reporting and planning interface is part of the platform, workflows can be built around how your teams actually work, not around a tool's template.

Plan for a read-only feed and clear ownership

Harper provides the data store, scheduled jobs, HTTP APIs, access control, application hosting, snapshots, and audit trail. Your team defines which Salesforce objects to sync, how often to sync them and which calculations need live read-only queries. Show users when synchronized data was last refreshed and distinguish it from live results.

Planning and forecast logic is application code you write. Define who can edit assumptions, and keep scenario results inside the application, since the sync never writes back to Salesforce.

Related resources

• Harper documentation: how data, application logic, jobs, APIs and authentication work on the platform.
• HarperFast on GitHub: public repositories and starter code for building Harper applications.

Start with one planning workflow

Pick one report your team rebuilds often and pair it with one scenario, such as a forecast under a slipped pipeline. Measure how long users wait for results, how closely the numbers match Salesforce, the number of products and handoffs involved, and the effort to maintain them. Include normal operation and one failure case, such as a sync that runs late or fails, and observe how clearly the application shows it. Discuss your architecture with Harper, and bring your current stack, your Salesforce objects and the reports you want to start with.

‍