Communities Issue – Unable to Create/Write Records on sn_communities_content from native viewIssue Unable to Create/Write Records on sn_communities_content. When trying to access this URL: https://<instance_name>.service-now.com/sn_communities_content.do?sys_id=-1 all the fields are displayed as read-only, and unable to create a new record. Symptoms unable to create a new record in sn_communities_content from native view. Release Any supported version. Cause The read only behavior is intentional and expected as per OOB. The read-only behavior in the backend forms for sn_communities_content and sn_communities_blog comes from different enforcement layers, and neither one points to a bug. Layer 1 — ACL on sn_communities_content (Create) :File: sys_security_acl_2564c1aedbca6200b1f6f78eaf96197f.xml The create ACL script checks forum_id and content_type — if either value is empty, it returns false. When you open sn_communities_content.do?sys_id=-1 (a new record), both fields are blank, so the script immediately returns false. That makes every field read-only before anything can be entered. Critical detail: admin_overrides = false — the admin role does NOT bypass this ACL. The same is true for the field-level create ACL on sn_communities_content.*. --- Layer 2 — ACL on sn_communities_blog (Create) :File: sys_security_acl_role_c427db3a87203200dd7756dfc0e3eca4.xml This ACL requires the "nobody" role, so no user can create a blog record directly from the backend form. That is intentional — sn_communities_blog is a child table of sn_communities_content, and blogs are always created through the portal flow, which writes to sn_communities_content first and then populates sn_communities_blog as a typed extension. Direct .do creation would create orphaned or malformed records. --- Layer 3 — Business Rule "Check UserAuthorization to Create record :File: sys_script_3fb6b14693332200dd773511e57ffb46.xml The BR runs on before insert and calls CommunityUser().hasContentAccess(). Your comment about the BR is partly correct, but the read-only form is driven by the ACL — the BR is an additional safeguard. They complement each other rather than duplicate each other. --- Why the Portal Works :The /community portal bypasses backend form rendering completely. Portal widgets call Script Includes directly with a valid forum context already in place, write to sn_communities_content server-side with a complete record (forum_id + content_type set), and the ACL script returns true. The blog record is then created automatically as a typed extension. --- Why editing ACLs Won't Help :Even after adding sn_communities.admin to their ACLs:• The sn_communities_content create ACL has admin_overrides: false• The sn_communities_blog create ACL requires the nobody role Adding roles will not fix the read-only form because the script returns false for any new blank record, regardless of role. Resolution This is intentional platform design. Communities content is meant to be created only through the portal or programmatically via Script Includes that provide the forum/content-type context. Direct backend form creation (.do URLs) is not a supported flow, and the ACL design blocks it to prevent malformed/orphaned records.