Supported Relationships

The definition of an extended formula can be simple or complex. This section describes which relationships the extended formula functionality supports. When a relationship is supported it means that if an extended formula exists and one of the events listed occurs, the system recalculates the extended formula. Relationships not described in this section are not supported.

The following relationships are supported:

Same Business Object

Formulas using fields or queries within its field’s business object are supported.

Single-Hop Query

Formulas that rely on the result of a query that has a $$RECORDID$$ association filter are supported. The association filter can be either a particular association type or the ALL association type.

For example:

  • Section = General
  • Field Type = Number
  • Name = triGrossAreaNU
  • Label = Gross Area
  • Input A and Input Type Query for Location---triFloor---triFloor – Formula – triBuilding – Total Gross Area---RecordInformation:triGrossAreaNumNU
  • Output of Record Information:Gross Area
  • Formula of A

Single-Hop Association

Formulas that rely on a field’s values in associated records are supported.

For example:

  • Section = General
  • Field Type = Number
  • Name = triHeadcountNU
  • Label = Headcount
  • Input a and Input Type Field for Parent For:Location:triSpace---RecordInformation:triHeadcountNU
  • Output of Record Information:Headcount
  • Formula of a

Multi-Hop Query

Formulas that rely on a query that references another query in its association filter are supported. This can reference queries n-levels deep. The hopping continues until a referenced query has a $$RECORDID$$ association filter.

The particular associations used in a multi-hop query are dictated by the query definitions. The association filters can be either a particular association type or the ALL association type.

For example:

(a) Building formula referencing a Space query:

  • Input A and Input Type Query for Location---triSpace---cstQuerySpaceForFloorsForBuilding---RecordInformation:triHeadcountNU
  • Output of Record Information:Space Headcount
  • Formula of A

(b) Association filter for the referenced Space query:

  • Association Type = ALL
  • Module = Location
  • Business Object = triFloor
  • Filter Type = Query
  • Record = cstQueryFloorsForBuilding

(c) Referenced sub-query that is a “hop” away from the Building formula:

  • Association Type = ALL
  • Module = -Any-
  • Business Object = All
  • Filter Type = Record
  • Record = $$RECORDID$$

Multi-Business Object Query

Formulas that rely on a multi-business object query where a $$RECORDID$$ field filter is against one of the query’s associated (non-primary) business objects are supported.

For example:

(a) Query Data Source Setup:

  • Module = Location | BO = Space | Association Type = -
  • Module = Location | BO = Floor (triFloor) | Association Type = ALL
  • Module = Location | BO = Building (triBuilding) | Association Type = ALL

(b) Query Field Filter Setup (e.g., System Filter Columns):

  • Field = System Record ID (triRecordIdSY) where BO = triBuilding
  • Report Label = System Record ID
  • Filter Operator = Equals
  • Value = $$RECORDID$$

Multi-Hop Association

Formulas that rely on a field’s value that is in a business object associated n-levels away from the business object that the extended formula resides within are supported.

For example:

(a) Pick Element:

  • minus cstBuilding
  • plus General
  • plus About---triPeople---triPeople
  • minus Contains---Location---cstFloor
  • plus General
  • minus Contains---Location---cstSpace
  • minus General
  • triHeadcountNU 🡸
  • triGrossAreaNU

Query Field Filters

A query referenced by an extended formula typically has field filters. If a record changes and the change is such that the results of a query could be affected, the extended formula system recalculates the extended formula.

Relationships between objects can be specified by a query field filter through $$RECORDID$$ filters and $$PARENT::[Section Name]$$ filters.

There are limitations to what the queuing and queue processing in the system acts upon:

  • Extended formulas are recalculated when a change to a record affects a filter applied to a field in the query’s primary business object. If the affected filter is applied to a field in an associated business object, extended formulas are not recalculated.
  • For multi-hop queries, extended formulas are recalculated when a change to a record affects a filter on the query directly referenced by the field formula. Extended formulas are not recalculated when a change to a record affects a filter referenced in any of the query’s related reports.

Not Supported

The following list of formula building relationships that are not supported is not exhaustive and by its nature cannot include every instance. If a formula building relationship is not explicitly listed earlier in this “Relationships the Extended Formula Supports” section as supported, it is not supported .

The list of non-supported formula building relationships includes:

  • Related reports that do not have association filters.
  • Query field filters on a non-primary business object.
  • In a multi-hop query, filters on queries that are not directly referenced by the formula.