Hello,

There's only been 1 solution proposed thus far and that's mine, so I assume you're addressing me and what I wrote.

Cloning a widget, it merely a way to jump start your own widget and either way, it's custom...on purpose. They want a feature that isn't available out of box, so...you have to create it. Your suggestion is also through a custom widget and altering the script to then embed another widget inside of it or...pay for a store app (which is also a custom widget or widgets on top/using out of box widgets).

Per your logic, no one should create any custom widget, which differs greatly from one of the major points behind the portal and widgets, etc.

In any case, custom widgets are being used.

You miss my point. I am not saying not to use custom widgets. I am saying not to clone OOTB widgets (for the reasons stated above).

Adding Button Support for the Data Table Widget can be achieved by either creating a custom widget and embedding the OOTB widget-data-table (wrapping technique) or even by adding a sibling-widget that injects the buttons (i have shown a proof of concept for this for the ootb widget-form in an article here in this forum).

Cloning a core component of ServiceNow is by far the worst of all possibilities, and if not maintained might maybe "include" one feature - but you lose every new feature to come by ServiceNow. Seeing just your own feature is very short sighted. If one would argue that he/she is still able to handle the maintenance of customized widgets, then he/she would also have the technically skills to implement it with the wrapping or injection technique.

In regards of paying for a app: After cloning, the widget will no longer be detected as modified by the ServiceNow Upgrade Mechanism. You will not be receiving any hotfixes either. By all means: The price you have to pay for implementing this to be on the OOTB-Level will be greater than what an app would cost.