{"id":31401,"date":"2025-10-30T05:54:47","date_gmt":"2025-10-30T05:54:47","guid":{"rendered":"https:\/\/www.greytrix.com\/blogs\/sagex3\/?p=31401"},"modified":"2025-11-29T19:30:40","modified_gmt":"2025-11-29T19:30:40","slug":"restricting-user-access-to-specific-sites-in-sage-x3","status":"publish","type":"post","link":"https:\/\/www.greytrix.com\/blogs\/sagex3\/2025\/10\/30\/restricting-user-access-to-specific-sites-in-sage-x3\/","title":{"rendered":"Restricting User Access to Specific Sites in Sage X3"},"content":{"rendered":"\n

When multiple sites operate under a single Sage X3 environment, giving every user access to all sites can lead to unnecessary complexity and security risks. With row-level permissions, administrators can precisely restrict users\u2019 access to one or a few sites based on their roles. This blog demonstrates how to implement these restrictions efficiently and maintain operational control.<\/p>\n\n\n\n

In multi-site Sage X3<\/a> environments, administrators often need to confine certain users to specific operational sites. This is primarily managed through Row-Level Permissions or Functional Authorizations. This guide explains how to implement such restrictions effectively while maintaining data integrity.<\/p>\n\n\n\n

Method 1<\/strong>: Restrict via Row-Level Permissions<\/p>\n\n\n\n

If an individual user should be confined to one or a small number of sites, you can utilize Row-Level Permissions. These permissions are configured in two key areas of the system: <\/p>\n\n\n\n

under Setup \u2192 Users \u2192 Row Level Permissions (to define permission codes) and within Setup \u2192 Users \u2192 Users \u2192 Organization tab (where you assign restrictions per user).<\/p>\n\n\n\n

New stuff:<\/strong> Validation on Non Existing PO field in Supplier BP Invoice Screen<\/a><\/p>\n\n\n\n

\"Fig<\/a><\/center>\n
Fig 1. Row level permissions<\/center><\/font>\n\n\n\n
\"Fig<\/a><\/center>\n
Fig 2. User wise row level permissions<\/center><\/font>\n\n\n\n

For instance, to limit a user to a specific site:<\/p>\n\n\n\n

1. Access Setup \u2192 Users \u2192 Row Level Permissions.
2. Search for the code linked to site-specific controls. Typically, this is ‘FCY’ used across multiple functions (e.g., POH, SOH).
3. Assign ‘FCY’ as the permission code for the selected user.
4. Under the Organization tab, specify the Key value (for example, NA10) corresponding to the desired site and save your changes.<\/p>\n\n\n\n

Once configured, logging in as this user will display only the assigned site (e.g., NA10) when performing actions such as creating purchase or sales orders. Note that Row-Level Permissions take precedence over any functional authorization settings.<\/p>\n\n\n\n

If I log in as the user and go to Purchasing, Orders, Orders and click on New, I will see that the only site available to the user is NA011.<\/p>\n\n\n\n

\"Fig<\/a><\/center>\n
Fig 3. PO filtered for site NA011<\/center><\/font>\n\n\n\n

Method 2: <\/strong>Limiting Access via Functional Authorizations<\/p>\n\n\n\n

When dealing with multiple users sharing the same function profile, using Functional Authorizations is more efficient. You can manage this from Setup \u2192 Users \u2192 Function Profile.<\/p>\n\n\n\n

\"Fig<\/a><\/center>\n
Fig 4. Functional profile<\/center><\/font>\n\n\n\n

1. Open the Function Profile screen and select the profile (for example, SABY).
2. Choose Authorizations \u2192 Addition \u2192 Recall to load all current authorizations.
3. Under the Type dropdown, choose either ‘Site’ (to restrict to specific sites) or ‘Site grouping’ (to restrict by site groups like company-level access).<\/p>\n\n\n\n

\"Fig<\/a><\/center>\n
Fig 5. Site grouping type\n<\/center><\/font>\n\n\n\n

4. Input the relevant site or site grouping code (e.g., NA10 for all sites under that group).<\/p>\n\n\n\n

\"Fig<\/a><\/center>\n
Fig 6. Grouping by site<\/center><\/font>\n\n\n\n

5. Check \u2018Forced Cancel and Replace\u2019 to clear pre-existing settings when creating a fresh rule, and save your updates.<\/p>\n\n\n\n

If additional sites (such as NA20 or FR011) need to be added later, repeat the process but leave the ‘Forced Cancel and Replace’ unchecked. This way, the user retains their previous site permissions while gaining access to new ones.<\/p>\n\n\n\n

Example:<\/strong> Granting Access to Multiple Sites and Companies<\/p>\n\n\n\n

Consider a user who needs access to all sites within companies NA10 and NA20, plus one standalone site FR011. You would create authorizations for the profile to include NA10 as a Site Grouping, then NA20 without replacing existing rights, and finally FR011 as an individual Site. This ensures the user can manage operations only within these designated areas.<\/p>\n\n\n\n

\"Fig<\/a><\/center>\n
Fig 7. Example of functional authorization<\/center><\/font>\n\n\n\n

Best Practices and Precautions<\/strong><\/p>\n\n\n\n

\u2022 Always test permissions using a copy of a function profile instead of modifying production ones directly.
\u2022 Verify that restrictions are applied correctly by performing sample transactions.
\u2022 Maintain backups of user settings before deploying changes.
\u2022 Avoid overlapping configurations between Row-Level Permissions and Functional Authorizations to prevent ambiguity.
\u2022 Regularly audit user access rights, especially after major version updates or role changes.<\/p>\n\n\n\n

By properly configuring Row-Level Permissions and Functional Authorizations, Sage X3 administrators can create a secure and well-regulated environment, ensuring users work only within authorized operational scopes.<\/p>\n","protected":false},"excerpt":{"rendered":"

When multiple sites operate under a single Sage X3 environment, giving every user access to all sites can lead to unnecessary complexity and security risks. With row-level permissions, administrators can precisely restrict users\u2019 access to one or a few sites based on their roles. This blog demonstrates how to implement these restrictions efficiently and maintain\u2026 Read More »<\/a><\/span><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8,13],"tags":[3857,1465,1632,1822,2018,2236],"class_list":["post-31401","post","type-post","status-publish","format-standard","hentry","category-sage-erp-x3","category-integration","tag-folders","tag-period","tag-recurring-task","tag-sage-x3","tag-schedule","tag-task"],"_links":{"self":[{"href":"https:\/\/www.greytrix.com\/blogs\/sagex3\/wp-json\/wp\/v2\/posts\/31401","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.greytrix.com\/blogs\/sagex3\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.greytrix.com\/blogs\/sagex3\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.greytrix.com\/blogs\/sagex3\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.greytrix.com\/blogs\/sagex3\/wp-json\/wp\/v2\/comments?post=31401"}],"version-history":[{"count":10,"href":"https:\/\/www.greytrix.com\/blogs\/sagex3\/wp-json\/wp\/v2\/posts\/31401\/revisions"}],"predecessor-version":[{"id":31530,"href":"https:\/\/www.greytrix.com\/blogs\/sagex3\/wp-json\/wp\/v2\/posts\/31401\/revisions\/31530"}],"wp:attachment":[{"href":"https:\/\/www.greytrix.com\/blogs\/sagex3\/wp-json\/wp\/v2\/media?parent=31401"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.greytrix.com\/blogs\/sagex3\/wp-json\/wp\/v2\/categories?post=31401"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.greytrix.com\/blogs\/sagex3\/wp-json\/wp\/v2\/tags?post=31401"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}