How to insert fields using ACLs, Business Rules, and Client Scripts.

[mugi-san]

Hello everyone.

We implemented ACL-based control to allow viewing the field without permitting value entry. A Business Rule was configured to set field values at the time of data insertion. A Client Script was implemented to visually simulate that a field contains a value, without actually setting one. Through this approach, we sought to ensure secure field value assignment under full ACL-based control.

(1) ACL

  Grant read permission via ACL. Alternatively, it’s not a bad approach to configure rules that indirectly deny permission by granting access only to users other than the intended individual.

(2) Business Rule

  We configure a simple rule to update field values upon insert. For more complex cases, script-based implementation may be required.

(3)  Client Script

  We configured a simple onLoad rule using g_form.setValue. Conditional branching should be implemented in the script to reflect the actual use case. This logic must be consistent with the Business Rule configuration. Given the ACL settings, the value set by this rule is expected to be disregarded at runtime.

In cases where it is undesirable for the entered content to exactly match its visual representation, or where user input is fundamentally not trusted, or where phrasing and display must be customized per user, it is possible to design the system to minimize data contamination under such conditions.
However, if—for example—only two individuals within the organization are shown a special display, while data visualization aims to treat all users' data at the same level of granularity, the situation remains visible only on the screen. As a result, users may be unaware of how their input was actually recorded, making it highly likely that neither they nor others can verify what they truly entered.

Thanks regards.

[mugi-san · Accepted solution]

Hello @Vishal_Jaiswal.

I apologize for not filling it out.

【Question】

Is there a good way to indirectly update a record without giving write permissions?

【Expected】

I don't think there is just one way, but do you know of any good methods?

Thanks.

[Vishal_Jaiswal · Accepted solution]

Hi @mugi-san ,

There are several ways to indirectly update a record without giving a user direct write permissions.

1) You can use on Submit Client script.

2) Flow Designer

3) Or you can use a Business rule, also where you can define custom logic in a script to manipulate the record.

From all the above ways, the record will be updated by the system.

Please mark this answer as helpful or accepted if it resolves your issue.

Regards,
Vishal

[Vishal_Jaiswal]

Hi @mugi-san ,

Can you please share your questions and the expected solution?

Regards,

vishal

[mugi-san · Accepted solution]

Hello @Vishal_Jaiswal.

I apologize for not filling it out.

【Question】

Is there a good way to indirectly update a record without giving write permissions?

【Expected】

I don't think there is just one way, but do you know of any good methods?

Thanks.

[Vishal_Jaiswal · Accepted solution]

Hi @mugi-san ,

There are several ways to indirectly update a record without giving a user direct write permissions.

1) You can use on Submit Client script.

2) Flow Designer

3) Or you can use a Business rule, also where you can define custom logic in a script to manipulate the record.

From all the above ways, the record will be updated by the system.

Please mark this answer as helpful or accepted if it resolves your issue.

Regards,
Vishal

[mugi-san · Accepted solution]

Hi @Vishal_Jaiswal .

Thank you for the idea. I conducted verification based on the idea.

Method [1]

The operating user needed write permissions to execute the Submit Client Script. Hence, when permissions were granted, it appeared to be a useful way to intervene in the user's process.

Method [2]

Since this method depends on the operating user's permissions, it needs to be executed as the system. As a result, any record updates will be logged as performed by the system. However, if that is acceptable, it seemed like a good approach.

Method [3]

ince it goes against best practices, using an "After Rule" to create a script that calls current.update() should be avoided, as it can lead to infinite loops.
In special circumstances, it is possible to include current.setWorkflow(false) in the script. However, doing so requires careful consideration of coexistence with other business rules that may be triggered, making it ultimately inadvisable.

Thanks regards.