Australia: conditional Knowledge update, attachment concurrency and durable operation proof
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
5 hours ago
Hello,
We are evaluating a scoped Knowledge integration on Australia using fictitious Draft articles. Automated writes remain disabled while we establish supported concurrency guarantees.
The Australia GlideQuery reference documents `where()`, `withAcls()` and `updateMultiple()` returning `rowCount`. The scoped GlideRecord method with the same name has a different return contract. We understand that a count alone is not a transaction receipt.
Could you point us to the supported Australia APIs/documentation for these requirements?
1. Are a GlideQuery revision predicate and its update evaluated atomically at database level? Does the ACL-aware path enforce the contributor's table and field write ACLs, and what exactly does the returned count acknowledge?
2. What supported mechanism also protects against concurrent attachment addition, deletion, binary replacement and attribute changes through standard UI/API/platform writers, including changes restored to their original value (ABA)?
3. Can the article update and an immutable operation record commit or roll back together? We need read-only recovery after a lost response, with an operation ID bound to actor, article and request digests, rather than automatic retry or body equality alone.
If this complete boundary is not supported, which narrower contract is supported? We are not looking for undocumented Glide internals, admin fallback, disabled ACLs/workflows or global policy changes.
References:
- https://www.servicenow.com/docs/r/australia/api-reference/server-api-reference/GlideQueryGlobalAPI.h...
- https://www.servicenow.com/docs/r/australia/api-reference/server-api-reference/c_GlideRecordScopedAP...
Thank you,
PPFTEC
