ITSM related
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
I'm working on a requirement where we need to ensure that once a record is moved to an 'Archived' state, it becomes read-only for everyone except the Admin. Should I lean toward a single Data Policy for UI-level control, or stick to a robust ACL (Access Control List)?
1 REPLY 1
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 hours ago
🔑 Data Policy vs. ACL
Data Policy
- Enforces rules at the UI level (forms, lists, Service Portal).
- Can make fields read‑only or mandatory, but it’s primarily client‑side control.
- Limitation: If someone uses APIs, integrations, or background scripts, a Data Policy won’t stop them from updating the record.
- Good for user experience enforcement, but not for true security.
ACL (Access Control List)
- Enforces rules at the server level.
- Controls who can read, write, or create records/fields regardless of how they access the data (UI, API, import, integration).
- Robust and secure — ensures that only Admins can update archived records.
- Best practice for security and compliance requirements.
⚙️ Best Practice Recommendation
- Use ACLs to enforce the read‑only rule for archived records.
- Example: Create an ACL condition that checks if
state == archived. If true, deny write access unless the user has theadminrole.
- Example: Create an ACL condition that checks if
- Optionally, add a Data Policy or UI Policy for user experience — so users see the fields as read‑only in the form.
- This avoids confusion and makes the restriction visible in the UI.

