Dear,
I am looking for a way to give the endusers the possibility to annotate record fields; so they can flag/annotate a field to indicate that the field requires follow-up.
I had tought of a simple data structure to allow this:
MyEntity:
ID | FieldA | FieldB | FieldC | FieldD | FieldE | FieldF | ... | FieldXXX |
1 | some value | |||||||
2 | another value |
TasksForMyEntity
ID | MyEntityRecordId | MyEntityField | Comment | Type | CreatedBy | CreatedOn | AssignedTo | DueDate | ClosedOn | CloseBy |
1 | 2 | FieldD | Please fill in this field | Task | Me | 01/01/2020 | You | 01/02/2020 | ||
2 | 1 | FieldA | This is wrong | Error | Me | 02/02/2020 | Me |
I think the data structure is quite easy to implement, so I can easily show all (open) tasks for a specific record.
What I don't know is how I can achieve this in a model-driven app (and eventually a canvas app); Somehow I want to be able to enable "annotation" on fields of an entity. When the annotation option for a field (of any type) has been enabled, an additional "flag" button should appear next to the field.
Is there any "standard" way to do this, does a plugin exist, or do I have to write this from scratch?
Thanks,
Koen
@HemantG , a "business rule" solution would not be useable imho.
Current example use case are more like:
... or is there a way to use "business rules" for these type of use cases?
Thanks,
Koen
It seems to be complicated and hard to configure solution. Also evaluate non PCF, client API/PBL based solutons which can iterate over the controls and use the recommendation and notification messaging - Create business rules and recommendations with Dynamics 365 for Customer Engagement (on-premises) | Microsoft Docs
hemant
Cool thought. Not the easiest implementation, but I guess you could write custom PowerShell steps into a DevOps Pipeline or GitHub Actions to extract the source, unzip it, identify the XML in question by entitiy, form, field based on some config file somewhere, then inject your own XML to automatically add the PCF with the appropriate config. It would be cool, to be sure, but I suspect it would be way more work than just adding the field one at a time... unless you're talking about adding this to like a hundred fields or more.
Hi @cchannon , really appreciate your help! It gets me really close to a solution (on paper, still have to do work though 😉 ). Once made, I will post it on PCF.Gallery...
I wonder if I could somehow "automate" the process of adding the PCF to a field? Otherwise, I have to add this PCF manually to all locations where an "annotated" field is put on a form...
Therefore, I think I should be able to add a custom field setting like "annotate field" (next to the default settings like "length", "required", "searchable",...). How can I achieve that?
Thanks,
Koen
Oh, and I mentioned before making a PCF valid for multiple types. If you ever need to do that, use something like this in your manifest:
<type-group name="all">
<type>SingleLine.Text</type>
<type>SingleLine.TextArea</type>
<type>Multiple</type>
<type>DateAndTime.DateAndTime</type>
<type>DateAndTime.DateOnly</type>
<type>OptionSet</type>
<type>Lookup.Simple</type>
</type-group>
Yeah, you definitely don't want to go building a ton of PCFs for this. You don't even want to build one PCF that can do all field types (although you can - in your manifest if you use a type-group you can declare multiple valid field types and thereby create a PCF that is valid for all those types... I'll add some sample XML at the bottom of this reply in case you ever want to use that in the future).
Instead, what you should do is just create one VERY simple PCF that is nothing more than a checkbox. Put it on any old column type - SLOT, bool, doesn't matter; let's call it new_reviewflag. Then, in your manifest add an additional Text input called "FieldName". Now, on the form you add that same new_reviewflag field to the form N times. In each case, put it next to the field you want to modify and put that field's name into the config input. In your PCF, when the box gets checked, you create your Task and include the input fieldname to tie it back. That should give you the UX you're seeking, which I believe is something like this:
@cchannon I like the PCF approach; I have already created some (small) ones before.
Can you direct me to an example how I can make a PCF that extends the existing functionality of fields? I don't want to create PCF components for all field types (text, number, date,...) but instead create a generic extension on all field types to add this "flag" functionality... (or maybe I should create separate PCFs for each type after all if that's faster/easier?)
OK, not for all fields - got you. But my answer still is the same; there is no OOB approach to this and you'll have to build it yourself.
A PCF is a good approach to the problem and will let you scale to an arbitrary number of these fields without having to create unnecessary schema, but if you don't feel comfortable in SPA dev, you could also use formscript (but only after creating an extra unique field for every field you want to associate this to) or Plugins (if there is no need for synchronous interaction with the user). You could even build a custom web resource for the purpose which would not require schema duplication but is definitely not the dev route MSFT wants us to be taking at this point.
Hi @cchannon , why do you think I want to duplicate each field?
My (custom or standard) entity will have a defined number of fields, but for zero,one or more fields of that entity I want to enable a (yet-to-make) "annotated field" option. When such a field is shown on a form, it should be accompanied with a "flag" button so the user can add a flag/task/annotation to that specific field of the current record.
There is no standard approach to this; it will need to be built from scratch. I would discourage you, however, from trying to accomplish this by duplicating every field; There is a limit to the number of columns that a given table can have (it is enormous, mind you, but it is limited) and needing to create two copies of every field is quite a headache when you make fields in the future, or need to build reports, or want to generate an early-bound class for plugins.
Instead, I would recommend you try to implement this in a more self-scaling way. A PCF, for example, could do this quite nicely. You could build a PCF that is valid for any field type, which presents as a checkbox (e.g.) and when checked creates those Task rows you're looking for. Then, instead of actually duplicating every column on the table, you simply add every field to the form twice and replace the second copy with the PCF so it gives you that checkbox experience you are looking for. You could even have the PCF pop a dialog window to get user notes immediately upon checking the box.
A couple Fluent UI React Components that would help you write this fast:
WarrenBelz
107
Most Valuable Professional
Michael E. Gernaey
72
Super User 2025 Season 1
mmbr1606
71
Super User 2025 Season 1