Component Record Input Property / With() Confusion

(0) Share

Report

Posted on by BenKraft

I have an input property to a component of type record (default/definition pictured):

I have a Dataverse table with the same column names. I understand that display names are different than schema names, so I understand that I am unable to do something like:

Since the names likely do not align in the backend. My thought was to "manually" create a record with With() from the returned Dataverse row:

- A

I thought I could use the ThisRecord operator since the scope would be the Dataverse record. Just to test things, I tried this:

- B

Which completely baffed me. Aren't I, here, regardless of the With() scope, returning the literal record {Name: "foo", Description: "bar, Image: "baz"}? How does it have none of the fields? Finally, I tried:

- C

Which works perfectly. How is this different than using ThisRecord ? Or even just the record literal?

Categories:

Building Power Apps

Microsoft Dataverse with Power Apps

I have the same question (0)

All responses (9)

Answers (1)

Suggested answer

SebS 4,653 Moderator on at

Like (0)

Report

Hi,

ThisRecord only has meaning inside record-scope functions, for example Filter, ForAll, AddColumns, GroupBy (and also galleries via ThisItem). In those contexts it refers to the current row being processed.

With() doesn’t create a “current row” scope. It just creates named values (variables) for the expressions inside it — similar in concept to UpdateContext, but scoped only to the With() block.

So inside With(), ThisRecord won’t automatically point to your Dataverse row. If you need the Dataverse row, store it in a variable (or use an alias like MyTable As dv) and reference dv.FieldName explicitly.

This is how this function is set up and exist :)

Was this reply helpful? Yes No
BenKraft 23 on at

Like (0)

Report

Hi @SebS,

Thanks for the tips! I'm not sure if it's entirely accurate to imply that With() isn't a record scope function and therefore can't use ThisRecord;

https://learn.microsoft.com/en-us/power-platform/power-fx/reference/operators#thisitem-thisrecord-and-as-operators

In fact, in other circumstances, it works perfectly well to use ThisRecord in regard to the first argument of With() as long as it is a record:

Do you happen to have any guesses as to why something like the expression in photo B I've attached above might not evaluate?

Thanks again!

Was this reply helpful? Yes No
SebS 4,653 Moderator on at

Like (1)

Report

Yes, that’s fair to add. ThisRecord can work if you clearly define the record scope. When the scope is explicit (for example inside ForAll, Filter, or when a record is clearly being processed), Power Apps knows what ThisRecord refers to.

When you use LookUp on its own, there’s no guarantee what record scope is active around it. In that case, ThisRecord becomes a guessing game — it depends on whatever scope already exists, which isn’t always obvious.

If you introduce something like ForAll, you’re working with a table and a clear current record, so ThisRecord may work there — but at that point the logic becomes harder to reason about.

That’s why the best practice is to name the record inside With() and use that name. It removes ambiguity, avoids relying on ThisRecord, and keeps the formula predictable and easier to understand.

Was this reply helpful? Yes No
Verified answer

SebS 4,653 Moderator on at

Like (1)

Report

In this case you’re effectively confusing the scope you’re creating. With the first argument of With(), you’re saying: “this scope is based on a record returned by LookUp”. That record already has its own fields and shape.

Then, in the same With(), you try to return a completely different record with hard-coded Name, Description, and Image values. Even though it looks valid to us, Power Fx doesn’t evaluate the second part if the first record argument isn’t cleanly resolved. It treats the whole With() as acting on the lookup record, and if that lookup is problematic or ambiguous, the formula fails before it ever gets to your hard-coded values.

So it’s not that the hard-coded record is wrong — it’s that With() first needs a valid, unambiguous record scope, and here that scope is already confusing or failing. Once that happens, Power Apps reports “none of the expected fields” because the formula never actually reaches the part where you define them.

That’s why naming the lookup result (or separating concerns) works better — it makes it clear what the scope is and avoids this kind of conflict.

Was this reply helpful? Yes No
BenKraft 23 on at

Like (0)

Report

@SebS Thanks for the help with this!

I think I understand what you're saying, that any data in the second argument of With() is interpreted within the first argument's scope? I wanted to see what this would look like outside of the context of the component input property, so just tested this in the Items field of a List box:

I think this makes sense, since the Name, Description, and Image are effectively being re-cast into the Dataverse table equivalents? (wtn being the publisher code of the table). Do you think I could then use something like wtn_description, wtn_image, and wtn_name as my component input record fields?

Was this reply helpful? Yes No
SebS 4,653 Moderator on at

Like (0)

Report

If I’ve understood your intentions correctly, I think it could work depending on the scenario, but there are a lot of trade-offs. You lose portability and readability, and it can get confusing when you move the app to another environment with a different publisher prefix. At that point, the component becomes tied to a specific Dataverse table instead of being reusable. Using Prefix_ColumnName basically hard-codes the component to that table.

Was this reply helpful? Yes No
SebS 4,653 Moderator on at

Like (0)

Report

Need to post it again I updated this post and it cleared whole post

So here is the component I created :

Here is my code and look how I pushing table ColleagueProfile.AbsenceData to the With()

With(

{

// Step 1: Prefilter using delegable conditions only

FilteredAbsenceData: Filter(

ColleagueProfile.AbsenceData,

DateTime >= DateAdd(

Now(),

-365,

TimeUnit.Days

),

EmployeeID = ColleagueProfile.EmployeeID

)

},

// Step 2: Build the cards using local (non-delegable) logic

Table(

{

Card: 1,

Title: "Absence Leave (Sick)",

Tag: "Sick",

Occasions: CountRows(

Filter(

FilteredAbsenceData,

AbsenceClass = "Sick",

HalfDayAbsence = false

)

),

DaysAbsent: Sum(

Filter(

FilteredAbsenceData,

AbsenceClass = "Sick",

HalfDayAbsence = false

),

DaysAbsence

)

},

{

Card: 2,

Title: "Emergency Leave",

Tag: "Emergency",

Occasions: CountRows(

Filter(

FilteredAbsenceData,

AbsenceClass = "Emergency"

)

),

DaysAbsent: Sum(

Filter(

FilteredAbsenceData,

AbsenceClass = "Emergency"

),

DaysAbsence

)

},

{

Card: 3,

Title: "Half-Day Leave",

Tag: "Sick",

Occasions: CountRows(

Filter(

FilteredAbsenceData,

AbsenceClass = "Sick",

HalfDayAbsence = true

)

),

DaysAbsent: Sum(

Filter(

FilteredAbsenceData,

AbsenceClass = "Sick",

HalfDayAbsence = true

),

DaysAbsence

)

},

{

Card: 4,

Title: "Other Leave (Suspended / AWOL)",

Tag: "Other",

Occasions: CountRows(

Filter(

FilteredAbsenceData,

AbsenceClass in [

"Suspended",

"AWOL"

]

)

),

DaysAbsent: Sum(

Filter(

FilteredAbsenceData,

AbsenceClass in [

"Suspended",

"AWOL"

]

),

DaysAbsence

)

}

)

)

You can do a lot of things using this kind of concept like pop ups inside of component with data here is example

If(

tabPeriodList.Selected.ID = 3,

With(

{

LiveAbsence: LookUp(

ColleagueProfile.AbsenceData,

EmployeeID = ColleagueProfile.EmployeeID && Status = "Live"

)

},

Filter(

ColleagueProfile.AbsenceData,

EmployeeID = ColleagueProfile.EmployeeID,

AbsenceClass = "Sick",

Status = "Close",

HalfDayAbsence = false,

// started before the 12-month window (but not earlier than 24 months)

DateTime >= DateAdd(

Today(),

-730,

TimeUnit.Days

),

DateTime < DateAdd(

LiveAbsence.DateTime,

-365,

TimeUnit.Days

),

// ended inside the 12-month window

RTWDate >= DateAdd(

Today(),

-365,

TimeUnit.Days

),

RTWDate < Today()

// Optional: Status = "Close", ID <> glbAbsence.ID

)

),

With(

{

InfoData: Filter(

ColleagueProfile.AbsenceData,

DateTime >= DateAdd(

Now(),

tabPeriodList.Selected.Days,

TimeUnit.Days

),

EmployeeID = ColleagueProfile.EmployeeID

)

},

SortByColumns(

Filter(

InfoData,

If(

varFilterTag = "Other",

AbsenceClass in [

"Suspended",

"AWOL"

],

AbsenceClass = varFilterTag

)

),

"DateTime",

SortOrder.Ascending

)

)

)

1 people found this reply helpful.

Was this reply helpful? Yes No
BenKraft 23 on at

Like (0)

Report

@SebS That makes sense, to keep the component versatile and publisher independent.

While it's not the super clean one-liner I was praying for, I think using the explicit With() record re-casting is my best bet. Appreciate all the help and explanation!

(Also what language do you use in your code snippet to mimic PowerFX?)

Was this reply helpful? Yes No
Suggested answer

SebS 4,653 Moderator on at

Like (0)

Report

I don’t usually use code snippets. I’ve found that if I copy the code directly from my app, it keeps the formatting. I’m often helping while I’m in the middle of development and usually have one or two apps open in edit mode, so even when I need to create an example, I do it inside an app and then just copy it across.

Was this reply helpful? Yes No