Formula Fields and Default Values
Salesforce Formulas
Pulsar directly supports evaluating Salesforce formulas both online and offline.
Supports formula fields
Supports default value field formulas (during initial record creation)
All numeric, logical, string, and date/time operators and functions are supported
Most summary and advanced functions are supported (some server-side-specific functions are not supported)
Set pulsar.formula.enableSFDCFormulas Pulsar Setting to TRUE to enable this functionality in the Pulsar mobile app
Notes and caveats
When syncing records, Pulsar picks up formula field calculations from Salesforce servers, and persists them to the local database
Formula fields are always recalculated on-the-fly every time you view a record detail page in Pulsar
Formula fields are NOT dynamically calculated in list views; instead persisted data from the local database is shown
For many organizations this default behavior is sufficient
But some organizations may encounter stale data situations (see below)
When creating or editing records, formula fields for that record are calculated and persisted to the local database
For many organizations this default behavior is sufficient
But some organizations may encounter stale data situations (see below)
Local persistence of formula fields and potential stale data
When Pulsar is online and syncs, formula field calculations are picked up from Salesforce servers and persisted locally. (NOTE that after the very first sync, there should be no stale data persisted to the local database, since all records have just been created afresh directly from Salesforce).
When online during record creation/edit, Pulsar will sync the newly created/updated record and also perform a readback that will pick up canonical formula field calculations from Salesforce servers. Also when creating/editing a record offline, Pulsar itself persists formula fields calculations just for that record to the local database.
So whether Pulsar is online or offline, formula fields are recalculated for the created/updated record, and persisted to the local database just for that record. So where can the stale data creep in?
It turns out that some formula fields are more complex than others. Simple formulas (our terminology) are those that only touch data from the record in question. Cross-record formulas (our terminology) are those that touch data across various records.
Objects that only have simple formula fields will always have coherent data stored in the local database
Objects that have cross-record formula fields will accumulate stale data in those formula fields because Pulsar does not recalculate formulas for all records that might be affected by a change
NOTE that stale data is not necessarily problematic for many organizations. The problems generally arise in the following scenarios:
Showing cross-record formulas in list views
Direct querying of cross-record formula fields in the database from custom code (e.g. SQL querying via PSL or via the Pulsar Javascript API).
Forcing formula field recalculations
If you are encountering stale formula data problems, luckily there is a mechanism from PSL shown here (as well as the Javascript API) to calculate and persist formula fields.
DEFAULT{
Action=CalculateSaveFormulas;
ObjectType=<ObjectAPIName>;
ObjectIds=<Optional comma-separated list of object Ids. If empty/unspecified, will operate on all records of ObjectType>;
WhereClause=<Optional WHERE clause to programmatically select specific Ids>;
FormulaFields=<Optional comma-separated list of fields. If empty/unspecified, will operate on all formula fields of the ObjectType>;
}Let's say, for example, you want to ensure that all formula fields on the Account object are always kept up-to-date in the local database when you are saving the Contact object. You can create an OnSave PSL Trigger (see the next section in the wiki about PSL Validation Rules and Triggers). The following example PSL will accomplish that:
DEFAULT{
Action=SetVar;
VarName=Account_Id;
VarValue=AccountId;
|
Action=CalculateSaveFormulas;
ObjectType=Account;
ObjectIds=%%Account_Id%%;
}WARNING: This can be an incredibly expensive operation if you do not specify any filter criteria. In the example above, had we not specified the ObjectIds parameter, then the calculation and persistence would run on all Account records!