Indeed it is in the Location Header.

From the related FHIR docs:

The server returns a 201 Created HTTP status code, and SHALL also return a Location header which contains the new Logical Id and Version Id of the created resource version:

  Location: [base]/[type]/[id]/_history/[vid]

where [id] and [vid] are the newly created id and version id for the resource version. The Location header should be as specific as possible - if the server understands versioning, the version is included. If a server does not track versions, the Location header will just contain [base]/[type]/[id]. The Location MAY be an absolute or relative URL.

See the RESOURCE Class Parameter of a Zen page, see related Docs.

Then you can provide or not provide permissions on this Resource for your Role.
 

Thank you for the update Mark, happy it's working well for you.

And thank you for posing your question on the community so it could be helpful for other users in the future, to make the usage clearer for them.

By the way, you mention testing, so you might find this tool useful in this context.

We have also added support for conditional updates within a transaction Bundle in version 2022.3 (i.e. a PUT with a conditional reference). 

You can try it out there.

Hi Mark,

Indeed all you need to do with your class/es is extend it/them from the DeleteHelper class. No need to add your own %OnDelete() method (in fact that might interfere with the method generation).

From your comment I cannot tell clearly enough what exactly did not get deleted (or of course why).

Per your question, in general what you can expect to see, as per the example I provided, is that the %OnDelete method (label) gets generated in the generated routine (INT).

If you want you can elaborate a little further about the full structure of your classes (you mention PathologyResult and FreeTextLine, but then later also Location which is unclear how it is related), and data (you just mention some ID numbers, but not really who's who), including message header info, and what you see when you purge the data (messages).

(if you want you can even share the actual classes, if you would prefer, also privately).

Maybe then I can be of more assistance.

Dmitry, following up on @Eduard Lebedyuk's comment, and even though you seem to say IIS is not the cause, this does "smell" like an IIS-related configuration.

I suggest you look here in the IIS docs, and in this related thread.

This setting enables to provide custom error pages instead of the "raw" downstream original server error (to be friendlier to users, or to possibly hide sensitive error details).

Try turning this setting off and see if this helps (if Apache is also available for example you can attempt testing with it as well to compare results).