USEREMAIL() seems overridden when adding a record from inside a grouped view

[sricse]

Hi everyone,

I’m experiencing an issue related to USEREMAIL() behavior when creating a record from inside a grouped view.

App Structure

• Table: Horas

• The view is grouped by Usuario

• Each worker logs their worked hours

• There is a column called Usuario

• The Usuario column has an Initial Value:

LOOKUP(USEREMAIL(), "Users", "Email", "Name")

The goal is simple: always assign the logged-in user’s name automatically.

---

The Issue

When:

1. An Administrator logs into the app

2. Goes to the Work Hours view

3. Selects a specific Worker group (e.g., Richter)

4. Clicks the Add (+) button from inside that grouped section

The new record shows the grouped worker’s name, not the Administrator’s name.

However:

• In the backend data source, the correct Administrator email is saved.

• The incorrect value appears in the app UI.

It looks like the grouped context is overriding or pre-filling the Worker column before the App Formula evaluates.

---

Expected Behavior

The User column should always reflect the currently logged-in user via USEREMAIL(), regardless of grouping context.

---

Question

Is this expected behavior when adding records from inside grouped views?

If so:

• What is the recommended way to prevent the grouped value from overriding the App Formula?

• Should this be handled with Initial Value instead of Initial Value?

• Is there a better architectural approach?

Any guidance would be greatly appreciated

[Suvrutt_Gurjar]

You may want to add more details

1. How exactly the said view is grouped. The grouping settings of the view.

2. Are you trying to say when user A ( Administrator) adds a record in the Horas table for a worker B, the form view shows the name of the user B in the column Usuario in the form view rather than that of user A?

3. Does it happen only in the form view?

4. In the example you have shared, is the user with the email soporte.smartd.pe
   Has that user created the record in your name? Also in the backend also there seems to be different record creator email and user name. You mentioned the issue is only in UI.

Could you clarify based on above questions?

[sricse]

Hi, thank you for your questions. Let me clarify the scenario in detail.

View configuration

• Table: Horas

• View type: Table

• Sorted by: Usuario (descending), Fecha (descending), HoraInicio (descending)

• Grouped by: Usuario and Fecha

• Group aggregate: by user (standard grouping, no special behavior)

User structure

We have a table called Usuarios where we manage:

• Allowed users

• Their profile (Admin or User)

There is only one Admin user (soporte@PII Removed by Staff).
All other users have the User role.

Column configuration

In the Horas table:

• Column: Usuario

• Type: Text (name)

• Editable? → No

• Initial Value:

LOOKUP(USEREMAIL(), "Usuarios", "Email", "Usuario")

This ensures the logged-in user’s name is always assigned automatically.

Additionally:

• A Security Filter ensures Workers only see their own records.

• The Admin can see all records.

---

Normal behavior (correct)

When a User logs in:

• They add a record.

• The Usuario column correctly fills with their own name.

When the Admin logs in and adds a record from the main view (not inside a specific group):

• The Usuario column correctly shows the Admin name.

---

The problem scenario

When the Admin:

1. Opens the Horas table view

2. Selects a specific user group (e.g., Usuario 2)

3. The view filters to only Usuario 2 records

4. Clicks the Add (+) button from inside that grouped section

The form shows Usuario = Usuario 2

Instead of:
Usuario = Admin

So yes — to answer your question:

When user A (Administrator) adds a record inside the grouped section of worker B, the form shows worker B’s name instead of user A.

---

Important clarification

• The issue happens in the form UI.

• The column Usuario is non-editable.

• It has an Initial Value using USEREMAIL().

• It should always evaluate based on the currently logged-in user.

Additionally, in our system the relationship between Email and Name is strictly 1-to-1 in the Usuarios table:

• If the email is sricse@smartd.pe, the Usuario value must always be Sahir Ricse.

• If the email is soporte@(PII Removed), the Usuario value must always be Rafael xxxxxxx.

There is no possibility of mismatch in our data model.

However, when the Admin adds a record from inside a grouped section (e.g., viewing Usuario 2), the form shows Usuario 2’s name instead of Rafael xxxxxxx.

In the backend audit log, the record creator email is correctly the Admin’s email.

This creates an inconsistency between:

• The actual logged-in user (email)

• The value displayed in the Usuario column

That is the behavior we are trying to understand.

---

Our question

Is this expected behavior when adding a record from inside a grouped view?

Is the grouping context supposed to override an App Formula in a non-editable column?

Or should the App Formula always take priority over the grouped value?

We appreciate any clarification

[Suvrutt_Gurjar]

Thank you very much for all the details. Your way of asking questions is really great with all the methodical details you provide.

I believe that one will need to set up exactly the environment to replicate yours before the said error can be reproduced. I am sorry that I have not been able to do that for lack for adequate time.

An alternative is someone from the support team can take a look at your app, if you are willing to share it with them. Or someone else in the community may provide you proper guidance based on the provided details.

[Steve]

When you add a row from a grouped view, the selected group column values are automatically supplied as initial values to the form, overriding the Initial value expression. It’s as if the form view were opened using LINKTOFORM("view-name", "group-column-name", [group-column-name]) (with appropriate substitutions). To get around this, add a virtual column containing the desired groupable value and group by that, then your Initial value formula for Usario will work.