#SFDC Integration0 discussing

Aiming to reduce the burden on Salesforce and improve overall performance:

1. Utilize Middleware Effectively:

• TIBCO as a Buffer: Leverage TIBCO's capabilities to:
  • Aggregate and Batch Requests: Combine multiple API calls into fewer, larger batches to reduce network traffic and improve efficiency.
  • Error Handling and Transformation: Handle potential errors from Epic's API and transform data to a format suitable for Salesforce.
  • Caching: Implement caching mechanisms within TIBCO to store frequently accessed data and reduce calls to Epic's API.

2. Optimize Salesforce Configuration:

• Bulk API: Consider using the Salesforce Bulk API for large data loads instead of individual DML operations.
• Asynchronous Processing: Utilize asynchronous Apex or Queues to handle API calls and data processing in the background, improving user experience for Salesforce operations.
• Governor Limits: Be mindful of Salesforce governor limits (e.g., concurrent callouts, DML statements per transaction) and design your integration accordingly.

3. Data Management Strategies:

• Denormalization: If certain data is frequently accessed, consider denormalizing it in Salesforce to reduce the need for multiple API calls to Epic.
• Change Data Capture (CDC): If only changed data needs to be synced, implement CDC mechanisms to capture updates in Epic and trigger corresponding updates in Salesforce.

4. Integration Patterns:

• Enterprise Integration Patterns (EIP): Explore patterns like Message Queueing or Publish-Subscribe to decouple Salesforce from Epic and improve scalability.

5. Performance Monitoring and Optimization:

• Monitor Performance: Continuously monitor API call performance using tools like Workbench or Apex Execution Logs.
• Profile and Analyze: Profile Apex code and identify bottlenecks for optimization.
• Performance Tuning: Tune heap size, governor limits, and caching mechanisms based on usage patterns.

Additional Considerations:

• Security: Ensure secure communication between Salesforce, TIBCO, and Epic using HTTPS and proper authentication mechanisms.
• Error Handling and Rollback: Implement robust error handling and rollback strategies to handle potential issues during data transfer.
• Documentation: Document the integration architecture, configurations, and procedures for future maintenance and scalability.

Categorization based on Data Flow and Processing:

1. Point-to-Point (Request/Reply):
   • Suitable for: Simple one-time interactions like medication refills, where Salesforce initiates a request to Epic and receives a response.
   • Considerations: High volume of calls can overload both Salesforce and Epic.
   • Optimization: Leverage TIBCO for batching requests and caching frequently accessed data.
2. Enterprise Service Bus (ESB) Pattern (using TIBCO):
   • Suitable for: Decoupling Salesforce and Epic, facilitating asynchronous communication, and centralizing message routing (especially for many API interactions).
   • Considerations: Requires additional configuration and management of the ESB (TIBCO in this case).
   • Optimization: Improves scalability and flexibility for handling various data flows.
3. Event-Driven Architecture (EDA):

• Suitable for: Real-time updates or notifications, like changes in patient profiles or scheduling updates.
• Considerations: Requires event streaming infrastructure and handling mechanisms for real-time data processing.
• Optimization: Improves responsiveness for situations requiring near real-time updates.

Additional Considerations:

• Hybrid Approach: You can combine these patterns based on the specific needs of each integration. For example, use point-to-point for medication refills and EDA for scheduling updates.
• Data Transformation: Regardless of the chosen pattern, TIBCO can play a crucial role in transforming data between Epic's format and Salesforce's format.

Choosing the Right Pattern:

The best pattern depends on the specific requirements of each integration:

Data Volume and Frequency: High volume or frequent calls might benefit from batching or an ESB.

Real-time Needs: Real-time updates might necessitate an EDA approach.

Complexity and Scalability: Complex integrations with multiple objects might favor an ESB for centralized routing.

My understanding and experience is exactly what you stated: Pardot does not create leads for Prospects that are matched to existing Contacts because it would create duplicates as the leads are worked in SFDC.

A few other ideas:

1) Create a task in SFDC when the form is completed. That way regardless of whether an existing contact is matched or a lead is created the SFDC owner has an action to take based on the form (not just an email to ignore).

2) Add all Prospects who submit the form ato a SFDC campaign and use the campaign status to track lead distribution

3) Record the form submission date in a custom field and have the lead distribution team use a report on that form to track existing contacts who have submitted the form.

You could also go the route of setting up an Automation Rule that looks for form submission and CRM Status of Contact and only do one of the above when the Prospect is an existing contact. However, you'll need to set up some sort of other dependency to make sure it doesn't get applied to Prospects when they are converted from a Lead to a Contact.

If they would like to create the api calls themselves, we have a developer area that can help them with creating much of the code and I have added the link to that page below. But as Milton stated, the MC Connector is the best app to use for connecting both programs, as it uses the api to make those numerous calls. So I am also baffled as to why they do not wish to use it, as it is solid and have been used for years by other MC accounts.

I use tasks for notification into SFDC as I don't know if the prospect is a net-new and will create a lead, an existing lead in SFDC or a contact.

Using tasks as the trigger for the new opportunity in SFDC gets around this ambiguity. You will have trouble with SFDC campaigns on the opportunities that are created off of contacts as they need to have the campaign manually associated.

You could have custom fields to hold the product info. Custom fields in Pardot aren't visible in SFDC.

You could set the HTML in the form to populate the comments field, which you can make visible in SFDC so the product is visible to your sales team. Some javascript in the form to move the selected products info into the comments field on form submission.

Pardot is a great accumulator of information. It isn't so good at holding onto discrete transactions like this. You have to be careful that bits of the prior order aren't pulled into the most recent order. I get everything pushed into the Comments field, as new entries are time-stamped. This gives a delimiter from last entry to the current entry.