Apsona for Salesforce is an add-on application that makes you significantly more productive when using salesforce.com
The software architecture of Apsona for Salesforce consists of
- A browser component, consisting of the user interface layer and a data transport layer
- A server component, consisting of one simple VisualForce page and one custom object.
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.com window, and manages all the user interactions. When necessary, it interacts
with the data transport layer, which in turn uses salesforce.com's
(Cascading Style Sheets) techniques for its display, and does not rely on any plugins.
On the server side, Apsona for Salesforce uses the salesforce.com's
native VisualForce technology. It comprises:
- A VisualForce page (named
ApsonaForSalesforce) which displays the Apsona for Salesforce user interface embedded within a salesforce.com tab.
- A single custom object (named
Apsona Item) which maintains information specific to Apsona for Salesforce, such as filters, reports, page layouts
and user preferences.
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
) 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.com'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.
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.com. 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.com itself uses, except that it is applied to browser-side software.
The core of our offering is a web application UI platform that constructs a rich Ajax-based user interface
entirely based on metadata (i.e., descriptions of the objects such as their names, labels, field names and
types). Our platform produces a user interface that addresses the most common data management use cases for web
applications, such as the standard CRUD operations, import, export, reporting and analytics facilities. The
metadata-driven architecture enables it to fully implement strong data validation at the individual field level
(such as dates, phone numbers, email addresses, currencies and pick lists) as well as reference fields across
multiple metadata objects. In addition, it exploits the reference field descriptions across the metadata objects
to produce desirable features such as smart querying, filtering with arbitrarily many terms, reporting with
multiple visualizations (lists, charts, pivots, and the like), child tabs, calendar views based on arbitrary
dates, and lookup of cross-object references when importing or exporting data. The user interface also offers
commonly-sought benefits such as retention of context, high responsiveness, lack of screen refresh, and a
pleasing look and feel.
Because of its reliance on metadata, the platform can be configured for almost any existing web
application. Integrating it into a new application is a matter of creating two components: the metadata
description in JSON, and a data service object that can talk to the back end service for the application.
In the case of salesforce.com, we are able to offer a similar integration. We rely on the metadata API
and describeSObjects) to dynamically create the metadata description for consumption by the
platform. We have created a data service object as a wrapper around the sforce.connection object included in the
This architecture enables us to defer to salesforce.com's API for field-level access
information (for data validation) and user security information (e.g., that a certain field is read-only or
inaccessible for a certain user).
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.