|The name of the connection as it will appear at our authentication point when there is a choice of connector.|
|The connection ID that needs to be specified in the API call payload. Pass this to your IT colleague before they begin their implementation.|
|The domain specific URI where the API will be expecting the POST. Pass this to your IT colleague before they begin their implementation.|
|Callback URL||An address in your site or application that users will be sent to for authentication (see: Implementing the API connector in your code)|
Not live = connection can only be used in debug mode. The visibility and default flags are ignored.
Live and visible (if this is the only local connection) = connection can only be used in debug mode.
Live and visible (if there are multiple live and visible connections) = users are offered a choice between this connection, using an OpenAthens account, and any other live and visible connections you haveof connections, including this one. There is a domain preference to include OpenAthens accounts or not.
Live & visible & default = This is your only login option and users will be sent directly to your login whenever the organisation is known. A successful authentication will tell the authentication point to remember that location. A failed authentication will clear that setting. Debug mode will not show other login options.
Changes to the status usually take effect within moments.
|Create local accounts|
Automatically - any user authenticated by your system and passed back to us is deemed ok and will be accepted by the system
Manually - only user IDs you have previously uploaded via the list page will be accepted by our systems
|Remove local accounts|
The salt used to generate a targetedID for users authenticated by this connection.
Modifying this after you go live will change the identifiers seen by service providers for your users... which is rarely desirable.