OroCRM business-unit hierarchy is part of the exposure boundary

OroCRM is part of the Oro application family. Its back office organizes users through roles, organizations, user groups, and business units. The business-unit hierarchy determines which records a user can access, including records owned by subordinate units.

That hierarchy changes how a reachable CRM should be reviewed. A role can allow an action on a customer, opportunity, or account record, while the business-unit tree decides which records the user can see. A correct role assigned at the wrong level can still expose a customer population.

ZoomEye returned 31 matches for title="OroCRM" on 2026-11-10 at 00:52 UTC. The application query returned zero, while the broad http.body="OroCRM" query returned 569,891. The body number is far too broad to treat as a product count. The title count is small, but a small CRM population can still hold sensitive customer and sales data.

View the title measurement in ZoomEye. The query used page 1, page size 1, and sub_type=all.

Roles and business units are combined

The Oro documentation describes roles as permission sets for entities and actions. Business units group users with related administrative tasks or roles, and permissions can restrict access for those units. A user can have division-level permissions that include selected units and the subordinate units beneath them.

The review should draw the actual tree and test access at its edges. A regional manager may need to see a regional unit and its child branches, but not a separate division. A finance role may need read access to accounts without permission to export every customer record.

Entity-level permissions should be tested separately from menu visibility. A user may not see an administration page but can still call a JSON:API endpoint for the underlying entity. The API and back-office role model should use the same owner and business-unit rules.

Integration credentials cross the hierarchy

Oro documentation lists OAuth applications and integrations such as JSON:API and SCIM. These are identities with their own access. A CRM integration may synchronize customer records, users, or account data across systems. Its credential should have a stated owner, business-unit scope, and rotation process.

Inventory integration accounts and their roles. Check whether an integration can create or modify users, change ownership, or read all business units. Test what happens when the integration owner leaves or the OAuth application is disabled. Remove applications that no longer have a business purpose.

Customer portals and storefront users are another scope. The Oro documentation distinguishes back-office users from customer user roles. A customer account should not inherit back-office permissions merely because it belongs to the same organization record.

Evidence and ownership

The ZoomEye title count is a discovery signal, not a claim that all 31 matches are production CRMs. Some pages may be login screens, demos, or custom deployments. The app zero is a fingerprint result. The body query cannot support a production count because the product name appears in documentation and unrelated content.

For each owned instance, record the business units, roles, integration applications, user groups, identity provider, and public network path. Review the organization owner and the people who can change the hierarchy. A change at the top of the tree can widen access for many users at once.

A practical test plan

Create a user whose role is limited to one business unit. Test a record owned by that unit, a record owned by a child unit, and a record owned by a sibling. Test the same records through the API. Verify that the result follows the documented hierarchy and the role's action permissions.

Then test a disabled user, an expired integration, and a customer portal account. The objective is not to prove that the CRM is inaccessible. It is to prove that the identity, role, and business-unit combination reaches only the records the business intended.

The external count is useful because it gives the review a finite starting set. The hierarchy is useful because it turns that set into an authorization test.

References

• Oro: Configure roles and permissions
• Oro: Configure business units
• Oro: Users, user groups, organization and business units
• ZoomEye title measurement for OroCRM

Measurement metadata: 2026-11-10 00:52 UTC, sub_type=all, page 1, pagesize 1; title 31, app 0, broad body 569,891.