---
sourceDocument: Brazil Platform security
sourceDocumentLink: https://www.servicenow.com/docs/r/platform-security

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil Platform security

ft:clusterId :

    - psec

bundleId :

    - psec

workflow :

    - Platform


---

# Double-check form submission

# Double-check form submission {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 1 minute to read  
When the system determines that a particular field (such as task.number) should not be
written to by the current user, the system renders that field in a read-only mode, which is why
the number field is not writable on most incidents.
If you set the system to double-check the values of any incoming fields for writability,
then the system applies the same set of security rules to the inbound leg of a transaction.
When you submit an incident, for example, the system double-checks to determine if the
number field can be written to before posting any changes.

If you tell the system not to double-check inbound transactions, then the system allows you
to write to a nominally read-only field if that is the transaction the client sends back. In
many deployments this is actually a desirable behavior if, for example, you are using client
scripts to set nominally read-only fields in response to user selections in other, writable
fields.
{#r_DoubleCheckFormSubmission__simpletable_oyj_zk4_kq__entry__3}

| Property | Location | Default |
|-|-|-|
| Double check security on inbound transactions during form submission (rights are always checked on form generation) | System PropertiesSecurity | Disabled (no double-checking) |
[Table 1.]

{#r_DoubleCheckFormSubmission__simpletable_oyj_zk4_kq}

*[\>]: and then