How to Manage Agreements
Your organization may have specific user agreements that apply to all users, or agreements that are applicable to specific users or types of accounts. We enable your application or product to prompt the user with various updates to agreements and handles also mapping agreements to consent.
How do agreements get triggered?
Organization Level Agreements
If you setup an active organizational agreement this will show to the user anytime they sign into ANY application under the project. Any organizational agreements trigger for ANY user that signs into your products. This is a good way to get a general agreement out to all parties.
Account Level Agreements
You're organizaton can define various account types, for example, a visitor account can have a specific set of agreements and consent requirements, where as a resident account can have more or different agreements, and finally a worker could have another type of agreement, etc. Your account types are specific to your domain.
You can trigger login flows with the account type by passing through the OIDC redirect parameter by adding a
&account={account_code}. This action will trigger the logic to execute the agreement checks for an account of that type.
App Level Agreements
At this level, your application itself will have its own various agreements, and signing them relate to signing them at your specified app. This is the most common use case.
Experiment Level Agreements
When triggering and opt-in for experiments the experiment itself may have various agreements that are requried, these will trigger when the redirect URL for OIDC contains the related experiment identifier `&experiment=xxx`.
Last updated