Tangilla leverages 3rd party Service API’s for Provisioning and Management.
IdP Provisioning and Management requires Fetch, Create & Update for the API.
IdP users accounts may (depending on the platform) support both members and offices, but ultimately thet represent a Relationship in Tangilla, specifically an IdPUser.
The Actions that Tangilla supports for IdP Provisioning are;
The Actions that Tangilla supports for IdP Provisioning (User) are;
The Actions that Tangilla supports for IdP Provisioning (Office) are;
Note that Tangilla does not require an Office Structure for IdP integration. It is preferred that Offices are not required by the IdP API.
While the specific fields required (and naming conventions) may vary from Provider to Provider all fields are expected to be based on the RESO Data Dictionary 1.7 and the following fields are anticipated to be available for Fetch, Create & Update.
| Field (reso) | Required | Searchable (Fetch) |
Notes |
|---|---|---|---|
MemberKey (reso spec) |
yes | yes | IdP UserName/MLSID, it is anticipated that this is the identifier that is used by the SSO system to identify the user. |
MemberAORkey (reso spec) |
yes | desirable | Primary Local Association NRDS ID |
MemberEmail (reso spec) |
yes | ||
MemberFirstName (reso spec) |
yes | Some states require this to match Licence | |
MemberMiddleName (reso spec) |
no | ||
MemberLastName (reso spec) |
yes | Some states require this to match Licence | |
MemberNickname (reso spec) |
no | ||
MemberNationalAssociationId (reso spec) |
yes* | desirable | Should be provided when available |
MemberMobilePhone (reso spec) |
yes | ||
MemberStatus (reso spec) |
yes | desirable | [A]ctive, [I]nactive |
| (https://ddwiki.reso.org/display/DDW17/OfficeKey+Field)) | |||
MemberStateLicense (reso spec) |
no* | desirable | required for Realtors/Appraisers |
MemberStateLicenseState (reso spec) |
no* | desirable | Required when MemberStateLicense present |
MemberAddress1 (reso spec) |
no | ||
MemberAddress2 (reso spec) |
no | ||
MemberCity (reso spec) |
no | ||
MemberStateOrProvince (reso spec) |
no | ||
MemberPostalCode (reso spec) |
no | ||
ModificationTimestamp (reso spec) |
yes | ||
OfficeKey (reso spec) |
no | no | Unique Key that identifies the office, it is expected this key does not change. |
| Field (RESO) | Required | Searchable (Fetch) |
Notes |
|---|---|---|---|
OfficeKey (reso spec) |
yes | yes | Unique Key that identifies the office, it is expected this key does not change. |
OfficeAORkey (reso spec) |
yes | Primary Association NRDS ID | |
OfficeNationalAssociationId (reso spec) |
yes | desirable | Office NRDS ID |
OfficeName (reso spec) |
yes | desirable | |
OfficeEmail (reso spec) |
yes | ||
OfficePhone (reso spec) |
yes | ||
OfficeStatus (reso spec) |
yes | desirable | [A]ctive, [I]nactive |
OfficeAddress1 (reso spec) |
no | ||
OfficeAddress2 (reso spec) |
no | ||
OfficeCity (reso spec) |
no | ||
OfficeStateOrProvince (reso spec) |
no | ||
OfficePostalCode (reso spec) |
no | ||
ModificationTimestamp (reso spec) |
no |
On creation of a new IdP account it is expected that the IdP API shall return an 'activation link' for the new user that supports the setting of a password. This link will be used in the welcome/activation message send to the user on account creation.