Titan Push/Get Best Practices: 7 Rules for Clean Salesforce Integration
Titan Push/Get Best Practices: 7 Rules for Clean Salesforce Integration
Push and Get are the two fundamental operations that connect Titan to Salesforce. Push sends data from Titan to Salesforce. Get retrieves data from Salesforce into Titan. Simple in concept, but the difference between a fragile integration and a bulletproof one comes down to these seven rules.
Rule 1: Never GET What You Can Pass as a Parameter
If the calling page already knows the record ID or user name, pass it as a URL parameter. Every unnecessary GET is an API call that slows the form load, costs against your Salesforce API limit, and creates a failure point. Reserve GETs for data that genuinely needs to be fetched live from Salesforce.
Rule 2: Always Enable “Do Not Overwrite if Empty”
When a user leaves a field blank, a standard Push sends null to Salesforce – which deletes the existing value. Enable the “Do Not Overwrite if Empty” option on every Push that updates existing records. This single setting prevents an entire category of silent data corruption.
Rule 3: Use Nested Pushes for Parent-Child Records
When creating related records (Account + Contact, Opportunity + Line Items), never fire independent Pushes. Use nested Pushes: the parent Push creates the Account and returns the AccountId, then the child Push creates the Contact using the returned ID. This guarantees referential integrity and prevents orphaned records.
Rule 4: Map Only the Fields You Need
Do not map every form field to Salesforce. Map only the fields that have business value. Empty fields that are mapped but not filled create unnecessary null writes. Unmapped fields are simply ignored – which is exactly what you want for optional fields that the user skipped.
Rule 5: Validate Before Pushing
Titan form validation and Salesforce validation rules are two separate systems. A Push that passes Titan validation can still fail Salesforce validation rules, required field checks, or trigger-based restrictions. Test every Push against your actual Salesforce org with realistic data – not just the happy path.
Rule 6: Enable Debug Mode During Development
Titan provides FT Debug Mode and Integration Logs that show the exact JSON payload sent with each Push and the exact Salesforce response. Enable both during development and testing. When something fails, you will see the specific field and error message instead of guessing. Disable debug mode before going live.
Rule 7: Handle Get Failures Gracefully
A GET can fail – the record was deleted, the user lacks permissions, or Salesforce is temporarily unavailable. Never assume a GET succeeds. Use conditional logic to check whether the global variable was populated after the GET. If it is empty, show a user-friendly message instead of a broken form with blank fields.
Quick Reference
| Rule | What It Prevents |
|---|---|
| Pass parameters, skip unnecessary GETs | Slow form loads, wasted API calls |
| Do Not Overwrite if Empty | Silent data deletion |
| Nested Pushes for parent-child | Orphaned records |
| Map only needed fields | Null overwrites on optional fields |
| Test against real SF validation | Push failures in production |
| Enable debug mode in dev | Blind debugging, wasted hours |
| Handle GET failures | Broken forms, blank fields |
Related Articles
- The REAL Pain Behind Salesforce Integrations – And How Titan Fixes It
- Architecting Solid Salesforce Integrations with Titan Push/Get
Explore Our Services
Want integrations built by experts? Contact Titanixforce – these 7 rules are built into every project we deliver.