Technical Information

Apsona for Salesforce is an add-on application that makes you significantly more productive when using Salesforce.

Software components

The software architecture of Apsona for Salesforce consists of

As far as back-end services, our technology relies entirely on the Salesforce SOAP API. Other than a single Visualforce page and a single custom object, there are no active back-end components (such as triggers, workflow rules, Apex classes etc.) in the application.

The browser component. The browser component displays the user interface within the Salesforce window, and manages all the user interactions. When necessary, it interacts with the data transport layer, which in turn uses Salesforce’s SOAP API. The browser component uses pure HTML, JavaScript and CSS (Cascading Style Sheets) techniques for its display, and does not rely on any plugins.

Salesforce components. On the server side, Apsona for Salesforce uses Salesforce’s native Visualforce technology. It comprises:

There are no triggers, validation rules, processes or other Salesforce components except the ones listed above.

Data access and access rights

Apsona for Salesforce relies heavily on the metadata aspects of the API calls (describeGlobal and describeSObjects) that Salesforce provides. This API includes information about what fields are accessible to and modifiable by the current user. This means that all of the profile information, sharing rules and access rights configured for the user are automatically inherited when the user accesses data via Apsona for Salesforce. In other words, the data and access rights available to the user via Apsona for Salesforce are exactly the same as those available directly via Salesforce’s native user interface. The user experience, however, is better (in our opinion).

Object visibility and access

Your Administrator can specify exactly which objects are visible and available via Apsona to a particular user profile, via the Apsona configuration mechanism. Moreover, if an object is unavailable to a user’s profile in Salesforce, it remains unavailable in Apsona, even if the Administrator has marked it visible in the Apsona configuration for that profile. Thus Apsona cannot be used to subvert Salesforce’s security mechanisms.

Software delivery

Our software is structured to deliver the browser-side components from our servers whenever the browser needs them, i.e., at the very moment when the browser requests the Apsona for Salesforce tab from Salesforce. This architecture offers several benefits:

We can deliver bug fixes and updates rapidly, since we can deploy fixes on our server and have them take effect immediately for our users.
We can customize the look, feel and functionality of the software to the needs of specific users and organizations.
Users need not be concerned about updating their versions of the software - it is done automatically.

Conceptually, this delivery model is virtually identical to the Software-as-a-Service (SaaS) model that Salesforce itself uses, except that it is applied to browser-side software.

Technology platform

Our application code is now fully hosted within the Salesforce ecosystem, utilizing Salesforce Static Resources for all front-end assets and distributed via AppExchange. This architecture eliminates the need for fetching any javascript code or media file from an external application server, ensuring that all data processing and operations occur entirely within the customer’s Salesforce org. This shift enhances data security, simplifies deployment, and aligns with Salesforce-native best practices.

At its core, our solution remains a metadata-driven, Ajax-based UI platform designed to construct rich, interactive web interfaces. Features such as data imports/exports, analytics, and reporting capabilities using the metadata are integrated in the Salesforce org itself.

All logic now runs entirely client-side within the browser, executed within the confines of Salesforce. Our JavaScript-based platform, previously partially reliant on server-side components, is now streamlined to function wholly on the client side using the Salesforce platform APIs for backend communication and security enforcement.

This updated architecture provides a fully self-contained, Salesforce-native experience that is secure, performant, and deeply integrated with the customer’s org structure and permissions making deployment, maintenance, and scalability significantly easier.

Data security and logging

An important consequence of this architecture is complete data security: customer data transmission is entirely restricted to between Salesforce and the browser, i.e., customer data never passes through any third-party servers. Even the generation of Word and Excel documents by the Document Generator add-on happens entirely within the browser. The only case where any form of customer data is transmitted to an external server is when a user invokes a Document Generator action to produce a PDF document. In this case, the Word document must be converted to PDF format (since that cannot currently be accomplished in the browser), so the Word document is sent over to our servers, which respond with the corresponding PDF version. To be clear: This external server is only used if (a) you have a license for the Document Generator add-on, and (b) you use the add-on to generate PDF documents.

There are two other types of information that we do track. One is user information, containing the user’s full name, user name and email address, so that we can provision licenses for users. The second is usage information, such as the actions that users take within the application. For example, when clicks the “Add to Campaign” button, a call is made to the Apsona servers to log that action. Our usage logs enable us to quickly determine and proactively fix bugs in the software, as well as to focus our development and performance enhancement plans on the most-used and most-useful aspects of our applications.