Subquery with a!queryRecordType

Hello — I would like advice on how to aggregate some data.

## Purpose
- The goal is to trace daily changes in workers' working hours.

## Data structure
- Each record represents a user's single work session and contains:
- **RECORD_ID**, **USER**, **START_TIME**, **END_TIME**, **DURATION**
- A user can have multiple sessions in one day, so one user can have multiple records for the same calendar day.

Example:

RECORD_ID | USER | START_TIME | END_TIME | DURATION
1 | A | 12/23 10:00 | 12/23 12:00 | 120
2 | A | 12/23 13:00 | 12/23 15:00 | 120
3 | A | 12/24 10:00 | 12/24 11:00 | 60
4 | B | 12/23 10:00 | 12/23 12:00 | 120
5 | B | 12/23 13:00 | 12/23 15:00 | 120
6 | B | 12/24 10:00 | 12/23 12:00 | 120
7 | B | 12/24 13:00 | 12/23 15:00 | 120
8 | B | 12/24 16:00 | 12/23 17:00 | 60
```

## Required aggregation steps
- First, aggregate these records by **user + work date** to compute each user’s total working time per day.
- Then, calculate the **average daily working time per organizational unit** (the organization each user belongs to) and trace that over time.

## Questions and constraints
- When editing directly in the database, we would use a subquery to compute per-user daily totals and then join to organization data.
- Is it possible to perform subquery-like processing when aggregating with Appian’s `queryRecordType`? In other words, can Appian perform the equivalent of the database subquery aggregation (group by user and date) before joining to organization and computing averages?
- I tried creating a database VIEW that computes users’ daily totals, but I gave up because I could not create the relationship between the user and organization in Appian. The user–organization relationship data exists in a central database, and it is difficult to join that at VIEW creation time.

Could you advise:
- Whether `queryRecordType` (or other Appian record/query features) can replicate the subquery aggregation pattern?
- Recommended approaches or alternatives in Appian to produce per-user daily totals and then aggregate those by organization (for example, using multiple queries, CDT transformations, database views, or integration to the central user–organization DB)?
- Any best practices for handling the central user–organization relationship when the relationship data is stored outside the record source?

  Discussion posts and replies are publicly visible