PingIDM

Organizations in high latency environments

The relationship-derived virtual properties (RDVPs) that support the organization model are generally calculated in response to relationship signals that travel down the organization tree hierarchy. Imagine, for example, that a new root organization is added to an existing organization hierarchy (or that a new admin or owner is added to the root of an existing organization hierarchy). The relationship signals that trigger RDVP calculation are propagated down the organization hierarchy, and to all members of the organizations in this hierarchy. This, in turn, updates their RDVP state. This propagation follows the same synchronous model described in Performance and scaling considerations.

If there are many thousands of members of the organizations in the hierarchy, this operation can take a long time to complete. It’s best practice to grow an organization hierarchy downwards, adding new organizations as leaves to an existing hierarchy, and adding new admins and members to the leaves in the hierarchy tree. This is preferable to growing the hierarchy upwards, starting with the leaves, and growing the hierarchy up towards the root.

If you must add a new root to an existing organization hierarchy with many organizations and many members, or a new admin or owner to an organization near the top of the hierarchy, perform this request over the command line instead.

Organizations with large membership

If an organization has a large membership (hundreds of thousands or more), adding an organization-level relationship, or anything else that triggers a notification, can take a long time to complete. The request that triggers it will likely time out on the client side before the server finishes propagating the change.

When modeling organizations with a large membership:

  • Avoid relationship configurations that notify all members of the organization on every change. Reserve notification for relationships and attributes that genuinely need to propagate to members.

  • Consider attributes configured with "notifyRelationships" : ["members"] that change frequently. Every update to this attribute signals all members. For example, a timestamp attribute with this configuration triggers a signal to every member on each update, which creates significant load.

  • Query organization membership using cookie-based paging rather than _pagedResultsOffset, especially for organizations with large membership. Learn more in Page query results.