Organisation contacts in Raidiam Connect
Organisation contacts are the contact details that ecosystem participants and administrators look up when they need to engage with a specific part of an organisation — for example, to report a technical issue, escalate a security incident, or resolve a billing question.
How contacts work
Contacts are registered by the organisation's users and serve as the primary point of communication between that organisation and other ecosystem participants. Several types of contact can be recorded in Raidiam Connect and should be kept up to date at all times.
Registering a contact inside Raidiam Connect does not grant that person any access to the platform or to the ecosystem. Only organisation users who have been explicitly added to Raidiam Connect have access to resources stored inside the platform.
Contact types
Contact types are ecosystem-configurable Reference Data, not a fixed, built-in list — the same pattern used for Flags. A typical ecosystem configures contact types similar to the examples below, but the exact set available to you depends on your Trust Framework Administrator's configuration.
| Contact type | Responsibility |
|---|---|
| Business | Business concerns, partnerships, and commercial matters |
| Technical | Technical problems such as performance, availability, and API integration |
| Billing | Billing, invoicing, and accounts receivable |
| Incident | Incident handling and incident response coordination |
| Security | Security matters such as certificate management and vulnerability disclosure |
See Configure Contact Types for how Reference Data administrators define and manage this list.
Each contact type also has an access level, which sets the minimum level of access a user needs to see contacts of that type. From least to most restrictive, access levels correspond to: public access, Domain User, Organisation Administrator, Data Administrator, and Super User.
Contacts registered at the public access level are visible to all ecosystem participants. Contacts registered at any other level are only visible to users of that same organisation who hold the corresponding access level or higher (Data Administrators and Super Users can see them regardless of organisation, since those roles aren't scoped to a single organisation). This lets an ecosystem keep certain contacts (for example, security contacts) visible only to trusted administrators.
Register contacts as a department or team (for example, security@example.com)
rather than an individual person. This avoids cases where a registered
employee's email becomes invalid and the contact ceases to be useful.
Contact entity fields
| Field | Description | Example |
|---|---|---|
| Contact Type | What the contact should be reached for | Account creation |
| Department | Department within the organisation | Technical |
| First Name | Contact first name | John |
| Last Name | Contact last name | Smith |
| Contact email address | john.smith@example.com | |
| Phone Number | Contact phone number | Country code - 1123456789 |
| Additional Information | Any supplementary details | Timezone - CET |
| PGP Public Key | PGP public key for encrypted communication | PGP Public Key |
| Contact Address | ||
| Address Line 1 | Premises number or name | Example Building 1 |
| Address Line 2 | Street address | Example Street 24 |
| City | City of domicile | London |
| Postal Code | Postal code of domicile | AA2A 3AA |
| Country | Country of domicile | United Kingdom |
