Baucore

External Data Providers

Conceptadmin

Baucore imports project data from more than one external source — ibau, Barbour ABI, MyProjectSales, and even Baucore Inbox’s email extraction — and all of them run on the same underlying provider framework rather than separate, one-off integrations. Understanding this shared layer makes it easier to configure any one provider, and it’s exactly what you’d extend to add a new one.

The core objects

ObjectPurpose
Prov_Search__cA saved search profile for a provider — encodes search parameters (region, project type, phase, etc.) as JSON, plus sync frequency (Daily/Weekly/Monthly/Yearly) and which user newly-imported records are assigned to.
Prov_Field_Mapping__cMaps a field coming from the provider’s data to a Salesforce target object and field. Each provider is identified by a value in the Provider__c picklist (e.g. baucoreInbox for Baucore Inbox).
Prov_Picklist_Mapping__cMaps a provider’s picklist string value to the corresponding Salesforce picklist API value, for any mapped picklist field.
Ext_Project_Credential__cPer-user provider credentials (username, password, login code), validated against the provider’s API on save, with the result written to a Status field. Uses Private sharing — only the owner and admins can see a given credential.

How a sync run works, end to end

  1. A scheduled job (a provider-specific scheduler, e.g. ibau_Sync_Scheduler or abi_Sync_Scheduler) iterates over active Prov_Search__c profiles.
  2. For each profile, it calls the provider’s API using the stored Ext_Project_Credential__c and the JSON search parameters in searchstring__c.
  3. Returned records are mapped to Salesforce fields via Prov_Field_Mapping__c, with picklist values translated via Prov_Picklist_Mapping__c.
  4. Participant creation follows the same role-mapping logic across every provider: a role that’s already mapped creates the participant automatically; an unmapped role holds for the user to map it before creation.
  5. If Auto_Sync__c is enabled on the search profile, subsequent changes detected by the provider are imported automatically on the next scheduled run — otherwise, matches are surfaced for a user to review and link manually.

Credential hygiene

Only one active credential (Active__c = true) should exist per user per provider. Deactivate an old credential before activating its replacement — the trigger handler re-validates against the provider API whenever a credential is inserted or updated.

Adding a new provider

This is the same pattern every existing provider follows:

  1. Create a new Ext_Project_Credential__c record type/flow for the provider’s authentication.
  2. Add Prov_Field_Mapping__c records with a new Provider__c value identifying the provider.
  3. Add Prov_Picklist_Mapping__c records for any picklist fields that need value translation.
  4. Implement a parser analogous to the existing provider converters, and a scheduler to drive it.
  5. Reuse the existing invocable classes (ProvCheckParticipant, ProvUpsertParticipantRecord) and Participant_Data.getParticipantBasedOnProjectAndAccount() for participant creation and deduplication — there’s no need to reimplement this layer per provider.

Still need help?

Our support team is happy to help with anything not covered here.

Contact support