Global API
Introduction
If you're a Salesforce developer or partner and need to connect Salesforce to QuickBooks programmatically, you've come to the right place. The Breadwinner Global API makes it straightforward to create automated QuickBooks integration points within Salesforce.
Here are some of the use cases where Breadwinner excels:
- Responding to your Salesforce code to read or write QuickBooks data
- Automating processes where accounting integration is involved
- Saving end users lots of time by supporting custom, automated logic
Breadwinner for QuickBooks Global API is part of the Breadwinner for QuickBooks managed package. A Global class is exposed as an API to allow our Breadwinner for QuickBooks customers to make calls to QuickBooks via Breadwinner, in addition to Breadwinner’s functionality.
How the permission check works in Salesforce for the Global API
In Salesforce, every kind of record (Invoice, Payment, Account, etc.) is stored as an object. Before a Global API action creates or updates a record, Breadwinner verifies that the Salesforce user making the request has Create and Edit access to every object the action touches.
There are two ways to grant that access:
- Assign a Breadwinner Permission Set that already covers it.
- Give Create and Edit access directly to every object that action touches, without going through a broader permission set - see the table below for exactly which objects each transaction type needs.
Either way, the user behind the request doesn't need to be a Salesforce or Breadwinner admin - just the object-level access itself.
If any of that access is missing, the action stops immediately and returns a message specifying exactly what's missing.
Insufficient access to sync the Invoice to Salesforce. Missing object access: Invoice (Create/Edit).
Whoever manages your Salesforce users can use this message to add the missing permission and try again.
NOTE: QuickBooks is always updated first. So if access is really missing, the record will already exist in QuickBooks even though it wasn't saved in Salesforce until the permission is added and the record is synced again.
Transactions and Objects that need access | Global API Actions | |||
|---|---|---|---|---|
Transaction type | Salesforce objects | READ | CREATE | UPDATE |
Invoices, Sales Receipts, Credit Memos | breadwinner_qbo__Invoice__c, breadwinner_qbo__Line_Item__c, Account, breadwinner_qbo__Breadwinner_Account_Connection__c | Read | Create | Read + Update; Delete rights for Line Item objects |
Bills & Purchase Orders | breadwinner_qbo__BW_AP_Bill_PO__c, breadwinner_qbo__BW_AP_Line_Item__c, Account, breadwinner_qbo__Breadwinner_Account_Connection__c | Read | Create | Read + Update; Delete rights for AP Line Item objects |
Payments | breadwinner_qbo__Payment__c, breadwinner_qbo__Payment_Transaction__c | Read | Create | Read + Update; Delete rights for Payment Transaction objects |
Bill Payments | breadwinner_qbo__BW_AP_Bill_Payment__c, breadwinner_qbo__BW_AP_Payment_Transaction__c | Read | Create | Read + Update; Delete rights for AP Payment Transaction objects |
Customers & Vendors | Account, breadwinner_qbo__Breadwinner_Account_Connection__c | Read | Create | Read + Update |
Invoice-specific note: Invoices also require Read access to the Salesforce User object when “Use Account Owner for Invoice Owner” is enabled in your org.
Understanding GAPI operations
- READ - Requires Salesforce Read access across relevant objects and fields.
- CREATE - Requires Salesforce Create permissions on applicable objects, along with field-level security for any populated fields.
- UPDATE - Demands combined Read + Update rights. Whenever transactions include child line items, Delete permission on those sub-objects is also necessary, since modifying a transaction can erase child records in Salesforce when removed in QuickBooks Online.
Warning: Object access alone isn't always enough. Salesforce also controls access at the field level, separately from the object as a whole.
So a user can have full Create/update access to every object below, and a GAPI action can still fail, because one specific field on one of those objects hasn't been made visible/editable for them. If that happens, check field-level security for that user's permission set, not just the object permissions.
Also, note that if your Global API uses any custom Salesforce objects or fields, the user running the Global API action must also have the required access to those objects and fields.
TIP: Clone the Breadwinner Admin User permission set, then strip out whatever objects and fields your integration doesn't use. Trimming down from full access is faster than building it up one field at a time.