Design Options

The platform frequently provides multiple ways to get the job done. This page provides an index of options for common tasks, and provides guidelines for choosing.

Choosing a Callable Process or Subprocess

Process designers have two ways to encapsulate process segments. The two options have slightly different behaviors. This section is designed to help you choose the one you need.

The options are:

• Subprocesses

• A big box inside of a process model, with it's own start and end points.
• A single exception handler can be used to trap all exception events that occur in the box.
  (So it's ideal when calling multiple Web Services, for example.)
• All record fields and all upstream process variables are available within the box.
• When running, it does not appear as a separate process in the user's sidebar.

Learn more: Subprocesses

• Callable Processes

• Created like any other Process, except that you set the Callable Process flag when saving.
• All record data is available, but there are no Process Variables (since it could be invoked by any process).
• Once launched, it appears in the user's sidebar, indented under the process that launched it.
  (The status flag shows whether it is Started or Completed.)

Learn more: Callable Processes

Note: In contrast to other Processes, a Callable Process: Can be called from a process step. (Other processes cannot be started that way.) Can only be called from a process step. (Can't be launched from a Rule, for example.) There are no [Start] or [Stop] buttons in the sidebar. You don't provide an estimate of anticipated duration, as you do with other processes (in the Process Target section).

Copying Data from Another Record

• If you have a Lookup field that targets a record you want to copy from, you can automatically copy the data as part of the Lookup settings. This mechanism works for simple data fields like text, number, and dates. When the user selects a Lookup target, the field data is automatically copied.

Learn more: Lookups#Copy Data

• If you have more complex data like formula calculations or attachments, you can put a Rule in a Rule set, and invoke that Rule Set whenever a record is added or updated. In this case, you define the rules on the object you want to copy from, and then update the record you want to copy to.

Learn more:

• Rules and Rule Sets
• Rule Actions (add and update record)

• To copy complex data from a target record, add post-selection JavaScript to the definition of the Lookup field.

Learn more: Post Selection JavaScript#Copy a Field from Another Record

Summarizing Data from Multiple Records

• Add computations to a report

• A computation in a report does not change the structure of the object, so it does not require any special design privileges. It can be defined by any user when creating or modifying a report.
• However, a useful computation may wind up being replicated in multiple reports, and such computations are available only when the report is run. So a summary of order-item amounts would not be available when a viewing an Order record, for example. In addition, to get the summary for one set of records, the summary for all sets of records is calculated.
• In general, then, report computations is most useful for data that does not need to be seen when examining an individual record. (For example, the total of orders for a given date, or for a given state.)

Learn more: Reports#Compute

• Calculate record summaries as related records are added and updated in a subform

• Related records like OrderItems have a Lookup to an Order record.
• A subform lets you total data for fields in those records as they are added or updated--for example, when adding an OrderItem to an Order. (The records can also be sorted on a selected column.)
• This is the most computationally efficient way to summarize data and store it in a record.
• It's limitation is that the calculated values are accurate only so long as the subform is used to add or change records.
• If APIs are used to add or change records, or if changes are made to the related records directly (for example, by adding a record to the OrderItems object, rather than adding it through the subform in an Order record), then the calculated values are no longer accurate.
• In addition, it provides column totals only. Other calculations like average, max, and min, are not available.

Learn more: Subforms

• Ongoing summary of data in related records using Rollup Summary Fields

• This is the most robust of the summary options. It is more computationally intensive, but the summarized data is always accurate, whether records are added or changed using APIs or a view of the related records.
• It can summarize data for wide variety of fields:

• Formula Fields that return a numeric value, as well as numeric fields.
• Decimal and percentage fields, as well as numbers and currencies.

(Data cannot be summarized for Boolean or Date fields, but that is rarely needed.)

• Synchronous summaries are the always accurate, because a new summary is calculated whenever data changes. (This is the kind of summary supported in the AgileApps Cloud platform cloud.
• However, the calculation is compute-intensive enough that a Service Provider may choose to make it unavailable in a hosted installation.
• In those installations, Asynchronous calculations are performed. They occur in the background, on a schedule determined by the Service Provider, so the displayed value may not be completely accurate for a short period of time.

Learn more: Rollup Summary Fields

• Summarize data in arbitrary records using Aggregate Functions

• When you define a formula field in a record, there are many contexts in which you can use one of the aggregate functions: SUM, AVG, MAXIMUM, MINIMUM, and record COUNT.
• Those formulas can be used on any object, and you can specify which records to include in the summary calculation. So they can be used for records that are entirely unrelated. A Lookup field is not required.
• However, the value is calculated only when the record that contains the function is created or updated. It does not automatically reflect changes in the set of records it operates on.
• These functions operate on simple fields only. They do not work for formula fields that return a numeric type.
• SUM and AVG work for number, currency, and Boolean fields.

MAXIMUM and MINIMUM work for number, currency, and Date fields.

• Because the functions do work for Boolean and Data values, they can be used, for example, to produce a SUM of records that have a Boolean flag set, or to get a MAXIMUM or MINIMUM date.

Learn more: Aggregate Functions