General Description

The Salesforce Interface (SFA) enables the exchange of Company data between Crawl and Salesforce, ensuring that both systems contain the same data. As of this writing, the systems that use SFA are Crawl, Salesforce, and iSee.

In the most common workflow, Salesforce is the Master of the data. This means that new company data is first entered into Salesforce and sent to Crawl using the automated SFA process. While the company remains a prospect, any changes to that data are done only in Salesforce and sent to Crawl. Crawl is therefore a Passive Receiver of data. Being passive, Crawl’s screens allow only read-only access to company data.

Note that there are other company data not in Salesforce that originate in Crawl and are therefore editable via Crawl.

All this changes when a company signs a contract with Sidewalk. With a signed contract, a prospect becomes a client, and the relationship switches, making Crawl the Master of the data and Salesforce the Passive Receiver. At this point, all changes to company data must be done in Crawl, which are automatically sent to Salesforce via the SFA interface. Additionally, Salesforce becomes read-only.



Includes the Crawl database, Oracle Forms, and all stored procedures, and related processes.


Third Party CRM that manages and views company data. Used for marketing and other company-tracking purposes.


Web application that is part-internal and part-external to Crawl.

Prospect or Client

A prospect or a client is a company in the companies database table. Within the SFA context, the essential difference between a prospect and a client is that a client is a company that has signed a contract with Sidewalk. All other Companies are prospects.

TIBCO Interfaces

The middle layer between Salesforce and Crawl that manages the messages and data sent between Crawl and Salesforce. Crawl does not connect directly to Salesforce. For any detailed discussion of Tibco, you will have to seek other documentation. 


<manageSalesforceProspect >


Soap Request manageSalesforceProspect, called by Salesforce (via Tibco).

Salesforce’s Company Data is sent using Soap elements, categorized in several Complex Types, which are then transformed into Java Classes. These categories break up the data into functional units.

These Java Classes are then sent as Key Value Pairs to package update_prospect.

There is one overall key to the data, the salesForceID.

Web Service profile codes: SFA_SYNC_PROSPECT, SFA_PROSPECT_ACK

This follows the process described below: Create or Update Prospect.

<manageSalesforceContact >


Soap Request manageSalesforceContact, called by Salesforce (via Tibco).

Contact Data is sent using Soap elements, categorized in several Complex Types, which are then transformed into Java Classes. These categories break up the data into functional units.

These Java Classes are then sent as Key Value Pairs to update_prospect_contact.

There is one overall key to the data (salesforceProspectID).

Web Service profile codes: SFA_SYNC_CONTACT, SFA_CONTACT_ACK

This follows the inbound process described below: Update Contact.



Soap Request manageExportProspectAck, called by Salesforce (via Tibco).

There are 2 keys: Salesforce Id + Crawl Company Code, which are sent using Soap elements, transformed into one Java Class.

Java Class is then sent as Key Value Pairs to export_prospect_ack.

This follows the process described below: Create or Update Prospect for iSee.

Inbound Acknowledgements

For all inbound processes, there is an acknowledgement:

  • OK
  • KO + Error

The format is standardized:

  • id, external_id, status_code, status_msg, status_date, event_type, data_type, external_syst_country

*Note that id and external_id are context sensitive: for all inbound calls, id = salesforce_id and external_id = Crawl; whereas, during outbound acknowledgements, id = Crawl id and external_id  = salesforce_id. This makes sense in that during inbound, the system sending the message is Salesforce, so its internal ID is the Salesforce ID and its external ID is the Crawl ID.


<manageSalesforceProspect >


Soap Request manageSalesforceProspect, sent to Salesforce (via Tibco).

This is the Payload for Company Data.

Database Triggers are used to call create_sfa_client_upd.

Web Service profile codes: SFA_CLIENT_UPD

This follows the process described below: Send Company Data to Salesforce.

<manageSalesforceContact >


Soap Request manageSalesforceProspect, sent to Salesforce.

This is the Payload for Contact data.

Database Triggers are used to call create_sfa_contact_upd.

Web Service profile codes: SFA_CONT_UPD

This follows the outgoing process described below: Update Contact.

Outbound Triggers

Triggers on the following tables are used to initiate the sending of Payloads.

  • Companies, Company_Partners, Company_Marketing, Company_Competitors, Company_Contacts, Employees, company_sales_report_codes, monaco_company_details, lease_out_headers.

The process is as follows:

  • Company data is changed via Crawl Forms or iSee or otherwise
  • One or more triggers on the above tables will call the SFA_WEB_INTERFACES package to create a payload and then use a set of Crawl functionality that takes the payload and sends it asynchronously to Tibco.

This above list of tables can be enlarged; essentially, any change to company data that is also present in Salesforce should trigger the payload process.

Process Described

Create or Update a prospect

The SFA web service exposes the operation manageSalesforceProspect to create or update a company’s data using the operation’s input parameters to pass company data.

This process is used only when the company is a prospect.

The same process to create a company is also used to update a company.

  • Whether to apply create or update logic, this is based on the incoming company’s SALESFORCE_ID: If the salesforce id is unknown, use INSERT; if it is known, use UPDATE.

Regarding company data:

  • Most company data comes from Salesforce “as is” – which means that most data is saved to the database without any change or business logic applied
  • However, there is quite a bit of business logic within SFA that must be understood
  • Most company data is saved into the COMPANIES table, but there are other tables such as COMPANY_CONTACTS, _PARTNERS, _marketing, _competitors, and others

The process:

  • User adds a company or changes data in Salesforce.
  • Salesforce calls a Tibco service and sends Tibco its company data.
  • Tibco transforms the data and calls the manageSalesforceProspect operation of the SFA web service.
  • Once SFA receives the call and its data, it runs the SFA PL/SQL package SFA_WEB_INTERFACES to save the data (as insert or update).

Create a prospect or client in iSee

Web Application iSee, being an extension of Crawl, follows a different pattern:

  • iSee gives the user the ability to create a prospect, just like Salesforce. It also enables the creation of a client on the spot.
  • iSee saves all company data to Crawl using Crawl’s native functions (which is quite complex: includes 3 different database schemas, java web services , and a number of oracle tables, packages and triggers. See iSee documentation for full description.)
  • iSee data is then sent to Salesforce via the same triggering mechanism for all Crawl-to-Salesforce communication.
  • With every initial iSee-to-Salesforce request, Salesforce responds by sending back a new Salesforce ID using the manageExportProspectAck operation, which is used to save the SF ID to that company’s Crawl record.

Send Company data to Salesforce (the “Payload”)

Once a contract is signed, the company becomes a client and the data is now managed within Crawl and Salesforce becomes passive. From this point forward, Crawl sends all updates to Salesforce via Tibco.

In order for Salesforce to always have the same data as in Crawl, there is an automated process which sends Crawl data to Salesforce.

Data sent to Salesforce is called the Payload, and the Operation used is manageSalesforceClient

The payload is an XML formatted collection of company data.

The Payload process is managed by Triggers, as follows:

  • On every change in the companies table, there is a database Trigger that automates the sending of the payload.
  • The SFA_WEB_INTERFACES package is used to group together company data into an XML-formatted Payload which is then sent off to Salesforce using built-in Crawl job-handling functionality that accesses Tibco asynchronously.
  • There are similar triggers on tables such as company partners, marketing, competitors, etc.

Update Company Contact

This is a simpler operation offered to Salesforce to maintain company contact information in both systems. Same processes apply as above.

Both outgoing and inbound operations are called manageSalesforceContact