The general wildcard fix is straightforward: replace Webapi/<table>/fields = * with an explicit column list before Microsoft removes wildcard support on 14 September 2026. For one table, that advice runs straight into Microsoft's own documentation.
msdyn_richtextfile, the attachment table behind the rich text editor control, has a tutorial that tells you to configure exactly the value the deprecation notice is removing. This post covers why that instruction is not simply outdated, what an incomplete field list quietly breaks, and the full list if you decide to enumerate it anyway.
Microsoft's own tutorial says: use the wildcard
Step 3.2 of "Configure the rich text editor control on Power Pages" lists the site settings required to store images through the rich text editor:
| Site setting name | Value |
|---|---|
| Webapi/msdyn_richtextfile/enabled | true |
| Webapi/msdyn_richtextfile/fields | * |
No deprecation note on that page, no alternative value mentioned. Meanwhile the deprecations article says the wildcard exposes all columns and is being removed everywhere. For most tables that is not a contradiction in practice, because your own code decides which columns it reads and writes, and you can list exactly those. msdyn_richtextfile is different: the consumer is a closed source PCF control, and it asks for different columns depending on what you are doing with it. Uploading an image is not the same request as uploading a file, and reading is not the same request as writing.
Note: This started as a real remediation, applied to a live customer environment as part of the general wildcard cleanup, not a hypothetical. The field list below is what fixed it, verified against Dataverse metadata, not guessed from the symptom.
Two blob columns, two different jobs
msdyn_richtextfile holds attachments for the rich text editor control, and it does that through two separate blob columns:
msdyn_imageblob
Base64 image content, set directly in the create payload. This is what a pasted or dragged PNG, JPG, or GIF uses.
msdyn_fileblob
A file column, read only in the Dataverse metadata (IsValidForCreate: false, IsValidForUpdate: false). Uploaded and downloaded through its own PUT/GET .../$value operation, not the normal create body.
That second part is the trap. msdyn_fileblob never appears as a settable field in a create or update payload, so a field list built by reading what the control actually writes will not include it. It still has to be present in Webapi/msdyn_richtextfile/fields, because the file column operation itself is permitted or blocked based on whether the column is in that list, independent of whether the column is writable through the normal payload.
What an obvious field list breaks
The generic wildcard fix, applied without knowing the above, tends to produce a field list built from the visible use case, image attachments:
Webapi/msdyn_richtextfile/fields → msdyn_imageblob,msdyn_parentidImage attachments, paste or drag and drop of PNG, JPG, GIF, keep working. Existing file attachments, PDF, XLSX, ZIP, stop being readable. New ones cannot be created either, and the two failures come from different code paths with the same error code:
That is the read path, on msdyn_fileblob. The create path fails the same way on a different column, msdyn_parententityname, which the shortened list also left out. Two missing fields, two error messages, both HTTP error code 90040101, both from the same site setting.
Warning: Image attachments continuing to work after the change is not confirmation that the fix is complete. It only tells you that the image path did not need the columns you removed. File attachments are a separate, silent regression until someone tries to open one.
The complete field list
The writable columns on msdyn_richtextfile, per the Dataverse entity reference, plus the read only file column the control still needs listed:
msdyn_richtextfileid,msdyn_name,msdyn_imageblob,msdyn_fileblob,msdyn_parententityname,msdyn_parententity_fieldname,msdyn_parentid,statecode,statuscodeThis list covers both attachment types and both operations, read and create. Applied against the case above, image and file attachments both read and both created correctly again. It is not a one off finding either: the same shortened list pattern showed up on a second, unrelated portal, with an added trap, that table existed as two separate site setting records with different GUIDs. Easy to miss if you are counting table names in the deprecation cleanup instead of counting site setting rows.
Note: System columns such as OwnerId are excluded here on purpose. The client never sets them itself, so they do not belong in a fields list scoped to what your code actually reads or writes.
If you want to enumerate it yourself
The list above is verified for the current rich text editor control, but "closed source PCF control" means Microsoft can change what it requests in a future release without telling you. Do not copy the list blind if you can check it live instead:
- Query
EntityDefinitions(LogicalName='msdyn_richtextfile')/Attributesagainst the Dataverse Web API and read the writable versus read only columns directly from the metadata, rather than from a blog post. - Test both attachment paths for real: an image attachment and a file attachment, each read and newly created. Four checks, not two, because read and create fail independently.
- Check for duplicate site setting records on the exact same table name before you conclude the setting is fixed everywhere.
- If you are not confident in the result, leave
*in place for this one table as a documented, deliberate exception rather than shipping an incomplete list. Microsoft's own tutorial backs that call for this specific setting.
That last point matters because the general rule and this exception are both correct at the same time, for different reasons. The general wildcard removal closes a real exposure on ordinary tables. This one table has a single, closed source consumer with variable field needs across scenarios, which is exactly the case the general advice does not cover well.
Why my maintenance clients already knew
The case behind this post came from exactly this kind of remediation work: a table fixed once, incompletely, then fixed properly once the real field usage was checked against the metadata instead of assumed. That is the difference a systematic review makes, and it is part of what Power Pages Care covers every month, not just when something is visibly broken.
I look after your portal so you do not have to. This is not a support contract with a bucket of hours. Four things happen every month, whether or not anything is going on.
01 Security and configuration review
Table permissions, web roles, site settings and identity configuration checked systematically.
02 Microsoft release check with a clear verdict
I read the release notes and the deprecation notices, you get the verdict: what affects your portal, what needs action, what you can ignore.
03 Written monthly report
Status, findings, recommendations, open items, in a form that also works for audit and compliance.
04 Smaller adjustments included
A bug fix, a permission adjustment, a form change. Anything bigger is agreed upfront.
Care is 1,290 EUR net per month, with a 48 hour response time on business days and adjustments up to two hours a month. Care Plus is 2,490 EUR net and adds a quarterly deep dive covering one audit area at a time, a 24 hour response time, same day for security incidents, and adjustments up to five hours. Minimum term three months, monthly after that.
You always know who to call. Onepager and terms at powerportals.de. Questions go straight to [email protected].
Related Articles
The Web API wildcard is going away on 14 September
The general fix: what the setting does, what breaks, and a 10 minute self check for every table on your site.
Read article → DevelopmentLiquid FetchXML vs. Web API in Power Pages
A decision tree, performance comparison, and security patterns between the two data access paths in Power Pages.
Read article →Sources
- Tutorial: Configure the rich text editor control on Power Pages, step 3.2, web API site setting values
- Rich Text Attachment (msdyn_richtextfile) table/entity reference, writable columns
- Rich Text Attachment (msdyn_richtextfile) table/entity reference, read only columns, including msdyn_fileblob
- Important upcoming changes and deprecations in Power Pages, section "Wildcard value (*) in Web API field configuration"
- Compose HTTP requests and handle errors for the portals Web API, error code table, code 90040101
