Table Custom not updated in methood put with postman

[felipe14]

Good morning, I created a custom table extending from the task, however I can't update the fields via Postman. I receive the 200 OK error, but the record isn't updated. Permission isn't a problem because I have admin access and I'm also working on a client instance, not my personal instance.

[23csb35]

Hello,

A 200 OK response in Postman means the REST request was processed, not that the record was updated. For custom tables extending task, this usually happens because the update is blocked internally. Common causes include using the record number instead of sys_id, using the wrong method (must be PATCH/PUT), field or table ACLs blocking write access (ACLs apply even to admin in REST), a Before Update Business Rule aborting the action, or a Data Policy enforcing mandatory or read-only fields. State models, dictionary overrides, or sending display values instead of internal values can also prevent updates. Checking ACLs, Business Rules, Data Policies, and confirming the correct sys_id and payload typically resolves the issue.

ThankYou

Ruba S

[BeingKhan · Accepted solution]

1) Quick sanity checks (1–2 minutes)

These eliminate common Postman / request problems.

1. Verify endpoint and HTTP method

   • Correct partial-update endpoint (preferred):
     PATCH https://<instance>.service-now.com/api/now/table/<table_name>/<sys_id>

   • Full replace (less common): PUT to same URL (but PUT expects full record).

   • Wrong endpoints often return 200 from some proxy/frontend but do nothing.

2. Confirm headers and auth

   • Content-Type: application/json and Accept: application/json

   • Authorization: Basic auth (username:password) or OAuth token with correct scopes. Admin credentials are ideal for testing.

3. Confirm request body uses column names exactly as in the dictionary (not labels). Example JSON:

{ "short_description": "API test update", "u_custom_field": "new value" }

1. Inspect the full response body (not only HTTP code). Table API returns result with the record fields; compare result.<field> to what you set.

2. Minimal cURL for a direct test (copy/paste):

curl -X PATCH "https://<instance>.service-now.com/api/now/table/<table_name>/<sys_id>" \ -H "Accept: application/json" \ -H "Content-Type: application/json" \ -u 'admin_user:admin_password' \ -d '{"u_custom_field":"test-from-curl"}'

If the response result shows your field changed, Postman config was the issue. If response shows old values or unchanged fields, continue.

---

2) If response JSON shows no change: quick Postman / client checks

• Confirm you are targeting the child table name (the actual table you created). If your table extends task but its table name is e.g. u_my_task or x_company_my_task, use that name in the URL — not task.

• Confirm sys_id belongs to a record in that table. Quick verify in browser: https://<instance>.service-now.com/nav_to.do?uri=<table_name>.do?sys_id=<sys_id>

• Try REST API Explorer inside the instance (System Web Services → REST API Explorer) to rule out external client issues.

• Try sysparm_fields to explicitly return the fields you changed: ?sysparm_fields=sys_id,u_custom_field,short_description — confirm the returned values.

---

3) Server-side checks (likely causes if client is correct)

If your request looks correct but the record remains unchanged, something server-side is preventing/rolling-back the change (Business Rule, Flow, ACL, Data Policy, Workflow). Follow these steps.

A — Look for Business Rules blocking/aborting updates

Business Rules are the most common cause of API updates that silently do nothing (they can abort, reset fields, or roll back).

1. List active Business Rules on the table (run in Scripts - Background😞

var br = new GlideRecord('sys_script'); br.addQuery('table','<table_name>'); br.addQuery('active',true); br.query(); while(br.next()){ gs.print(br.name + ' | when=' + br.when + ' | order=' + br.order); }

1. Search for scripts that call setAbortAction(true) or current.update() (may revert or block):

var s = new GlideRecord('sys_script'); s.addQuery('script','CONTAINS','setAbortAction'); s.addQuery('active',true); s.query(); while(s.next()) gs.print(s.name + ' on ' + s.table); var s2 = new GlideRecord('sys_script'); s2.addQuery('script','CONTAINS','current.update'); s2.query(); while(s2.next()) gs.print(s2.name + ' | ' + s2.table);

1. Enable Debug Business Rule: System Diagnostics → Debugging → Debug Business Rule (turn on), then make your API call and review the debug output to see which BRs fired and their actions.

If you find a BR that aborts or sets fields back:

• Inspect its condition and script. Temporarily deactivate (on a sub-production clone) or add logging (gs.info()) to understand flow. If it’s essential logic, modify to let API updates through (e.g., protect only certain states, or detect API contexts via gs.getProperty('some.integration.flag') or by checking gs.getSession().isInteractive()?).

B — Flow Designer flows or legacy Workflows

Flows can run on update and change fields after the API call returns.

• In Flow Designer, search for flows where the Trigger is your table and the event is Record updated. Check for actions that overwrite your fields.

• To test: temporarily disable the flow (or replicate test on a sub-prod clone). Or add logging actions.

C — ACLs and field-level security

• Check table and field ACLs: System Security → Access Control (ACL). Field-level ACLs may block write. However, ACL violation usually returns 403 — but if a script handles it, behavior might differ.

• Confirm the integration user being used in Postman has roles required to pass any scripted ACL checks. Test by using the instance admin user.

D — Data Policies and Dictionary attributes

• Data Policies with "Server" enforcement can prevent changes. Check Data Policy records for your table.

• Check the field dictionary to see if attributes like read_only or custom attributes prevent writes.

E — Workflows / Business Rules causing transaction rollback

• A Business Rule might current.setAbortAction(true) or throw a handled exception, leaving the API with success but no update. Look at System Logs → System Log → All for entries at the time you sent the request.

• Check asynchronous BRs/background jobs that get queued and overwrite values later. System Scheduler or sys_trigger entries may show queued jobs.

---

4) Diagnostic queries & audit trails

Use these to prove whether anything changed behind the scenes.

1. Check sys_audit for changes to the record:

var aud = new GlideRecord('sys_audit'); aud.addQuery('documentkey','<sys_id>'); aud.addQuery('tablename','<table_name>'); aud.orderByDesc('sys_created_on'); aud.query(); while(aud.next()) gs.print(aud.sys_created_on + ' | ' + aud.fieldname + ' | ' + aud.oldvalue + ' => ' + aud.newvalue);

If nothing is recorded, the record was not committed.

1. Check sys_history_line for form history if auditing is enabled.

2. Transaction debug: System Diagnostics → Transactions (or use Debug Transaction) to capture what happens when you call the API.

---

5) Isolation test: rule out server logic by updating via server script

If a server-side GlideRecord update works but REST does not, that points to flows/BRs/ACLs acting on web services only.

Run in Scripts - Background:

var gr = new GlideRecord('<table_name>'); if (gr.get('<sys_id>')) { gr.setValue('u_custom_field','script-bg-update-' + new Date().getTime()); var id = gr.update(); gs.print('update returned: ' + id); }

• If this successfully changes the field, server has no fundamental lock — something specific to API execution flow (BR/Flow/Data Policy) is interfering.

• If this also fails, the problem is deeper (dictionary/config or field-level protection).

---

6) Check for “same value” behavior and caching

• If the value you submit is identical to the existing value, ServiceNow will not change sys_updated_on or create sys_audit entries. Confirm by setting a unique value like khan-test-<timestamp> and recheck.

• UI caching: refresh the record in the browser (not the list) or re-query via API to be sure.

---

7) Additional things to inspect (less common)

• Scripting that runs only for web services: Some scripts check gs.getSession().isInteractive() or gs.getProperty() to behave differently for APIs. Search for isInteractive or REST references in scripts.

• Reference qualifiers or calculated fields that overwrite values via scripted scheduled jobs.

• Update set locking or special EHR/protected record types (rare in custom task tables).

---

😎Prioritized, actionable checklist (do these now)

1. Re-run your Postman PATCH with u_custom_field set to a unique test value and inspect full response JSON.

2. Try the same change using curl or REST API Explorer in the instance. If curl works and Postman doesn’t — fix Postman. If neither works, continue.

3. Run sys_audit query for the record to see if any audit lines were created.

4. Run the GlideRecord snippet in Scripts - Background to see server-side update behavior.

5. Enable Debug Business Rule, make the API call, and read debug trace to see which BRs fired.

6. Search active Business Rules and Flow Designer flows for your table (look for aborts, setAbortAction, current.update(), or overwrites).

7. If you find a suspect BR/Flow, disable it on a sub-prod clone and re-test, or add gs.log entries to trace the logic.

8. Review Data Policies and Field ACLs for the exact fields you are trying to update.

---

9) Most likely root causes (and fixes)

• Wrong table name / wrong sys_id — Fix: use correct child table name and correct sys_id.

• Client request using wrong field names or missing Content-Type — Fix: use exact column names and Content-Type: application/json.

• Business Rule aborting or resetting the field — Fix: modify BR logic to allow API updates or guard the BR with a condition.

• Flow Designer flow overwriting values — Fix: adjust flow or scope conditions so it does not overwrite API-set fields.

• Data Policy / Field ACL preventing update only for web services — Fix: adjust policy or ACL, or use integration user that can pass scripted checks.

• Request not actually arriving at the instance you think (different instance / instance alias) — Fix: confirm instance URL.

---

10) If you want, I can:

• Generate an exact Postman request body and header set for your table (I’ll make placeholders you can paste).

• Produce the exact Scripts - Background snippets tailored to the table name you give so you can search BRs/Flows quickly.

• Draft logging snippets to drop into suspect Business Rules to trace execution.

Please Mark the Answer Helpful & Accept it as a Solution if you found it correct.