Skip to main content
Populations allow users to group entries within an analysis to support more efficient sampling. Unique populations can be defined within libraries, engagements, and analyses, and can be used to surface or exclude groups of entries from the analysis results. Some fields (below) within population entities may only be defined for populations depending on their parent entity. Library populations:
  • libraryId
Engagement populations:
  • engagementId
  • derivedFromLibrary
  • disabledForAnalysisIds
  • promotedFromAnalysisId
Analysis populations:
  • analysisId
  • derivedFromEngagement
Each population inherits permissions from its parent entity type. In order to access library, engagement, and analysis populations, you will need to be able to access libraries, engagements, and analyses respectively. If the API token does not provide sufficient access, those populations will be excluded from GET and /query results.

​
Population conditions

Populations use the same condition format as saved filters. Please refer to the saved filters documentation for a description on how the condition formats work. Population conditions have additional restrictions in addition to those applied to saved filters:
  • The following fields cannot be used as part of a population condition: populations, account_tags_decreasing, account_tags_increasing, status and risk_range.
  • Populations can only be applied to general ledger analysis types.
Unlike filters, populations are validated on creation and when updated. A create or update to a population condition that doesn’t align with the analysis’ data table definition will fail. Additionally, unlike filters, populations can only be applied to general ledger entries, not transactions. Similar to filters, populations include the fields legacyFilterFormat, displayCurrencyCode and displayLocale, which function in the same way as they do for saved filters.