Custom to Quickbooks Online (QBO) Integration

Standard Vs. Custom Integration

One of the issues I face almost daily is the to Quickbooks integration question. Many of our clients go with a company that does nothing except sell a pre-configured integration - essentially the same integration to all of their clients. These third party integrators do a good job with a standard integration, typically that means that the integration will connect an Account in salesforce to a Customer in QB, an Opportunity in salesforce to an Invoice in Quickbooks, and Opportunity Product Line Items in to Invoice Line Items in Quickbooks Online.

This is okay for some people who are using the standard sales cloud in Where clients really run into issues is the non-typical implementation. That is where custom integration comes in. The custom integration between and quickbooks online gives us unlimited options.

Native to

A custom integration is written in Apex and resides in; therefore, there are no servers, no third parties, no external codes. We write the code in your instance of where it is executed when required and communicates via a secure channel (OAuth) directly with Quickbooks online.

Custom Integration Possibilities are Endless

Let me give some examples (these are just a few common needs I've seen, but since it's custom, we can literally do anything that a customer might require):

- Maybe you just want to keep the accounts in Salesforce integrated with the customer accounts in Quickbooks Online. Or a variation on that, maybe you want a particular Contact and its associated Account in to be associated with the customer account in Quickbooks. The integration can be written to pass any and all records, or just those that pass some criteria. We can even initiate a check from salesforce against quickbooks to ensure a customer record is up to date, or check on a regular basis for new records in Quickbooks and bring those into

- After a sale is complete in Salesforce, either in an opportunity or perhaps a custom object that you use like Sales, Invoices, Jobs, etc, you'd like to have the details of that record passed from to QBO as a new Invoice and its line items - easy; just tell us the objects and fields involved and we'll write the integration accordingly.

- Some clients don't enter every sale in Salesforce, they just use it to win the relationship. After that the client makes purchases that show up in Quickbooks and you just want to see their invoices and the status of those invoices against the Account record in - no problem. We can run a batch on a regular basis that looks for any new invoice activity in Quickbooks and brings that into a custom object in Salesforce, possibly an Invoice object, a Sales object, or a Billing object.

Moving Forward

So how does this get done? In a nutshell, we meet with a client online (via Gotomeeting), look at their instance together and determine the project requirements. If they need setup work first in, such as creating custom objects and fields to support the business processes, we'll be happy to do that - then when ready for the integration with Quickbooks Online, we'll map the objects and fields to the Quickbooks online database and fields.

Once the requirements are determined, our developers write the integration and install it directly into the client's instance. This can typically be accomplished in just a few days. After the code is installed in your sandbox, we'll test it together to determine if it satisfies your requirements and upon your acceptance of the code we'll deploy it to your production environment and release it to your various users.

Pricing for a Custom Integration

As a consulting company, we charge hourly rates (see our website for current rate In some circumstances we'll do a fixed bid if the requirements are clearly articulated at the beginning of the project. While there are many variables that can ultimately affect the final price, the typical integration will normally be under $4500. Once its paid for, the code belongs to the client - no ongoing fees or subscriptions (that alone can make its long term value much greater than even the standard integrations).

Get Started?

If you'd like to speak with us about doing a custom Salesforce to Quickbooks integration for your company, you can reach us through our website at

Conversion between Person Accounts and Business Accounts

Selling Business to Business was designed mainly for the business to business sales model. Their architecture supports this beautifully. Accounts are companies that you work with. Contacts are the people at those companies that you work with. This design is a huge improvement over contact centric databases like Outlook where you may have the same business noted in your database against several different contacts, but in each case spelled slightly differently (like Snapptraffic, Snapptraffic Consulting,, etc)

This architecture presents a challenge however to the business that sells directly to consumers. There is no need for an Account record in this situation. While that consumer might be associated with a company (where they are employed), the business has no need in most cases to track those details and isn't selling to that person's place of employment. I've seen businesses try to adapt the salesforce account/contact architecture to that business to consumer reality in many different ways, but none of them are all that great.

Selling Business to Consumer - Person Accounts

So decided quite a few years ago to offer a modification to their out-of-the-box architecture that deals with this challenge. It is called Person Accounts. Person Accounts are only available in Enterprise Edition and are only available by request. A support representative will actually have to enable this in your system by making a permanent modification (that's right - once enabled, they can't be disabled).

Person Accounts are really just an Account Record Type. They are a hybrid between accounts and contacts where a contact record is "jammed into" the account. They are tied together, so to speak, so that only one contact exists at the account. The resulting record is both an account with all of it's fields and a contact with all of its fields. When doing a lookup from other objects to a person account, if the object has a lookup to a contact record, then the object can lookup to the Person Account. Likewise, if the lookup is to an account, the object can lookup to the Person Account as well.

This structure now provides a user with the means to say that "Billy Bob Smith" is my client. The fact that Billy Bob works at Acme is irrelevant and no longer needs to be entered.

Working with Both Business and Person Accounts

It is a great solution and works very in almost all situations. Some companies work with both businesses and consumers though. Say, for example, a company that paints buildings. Sometimes they'll be selling to an individual home owner, in which case a Person Account would work best. Other times they'll be selling to a business, like a law office, in which case a Business Account would be used. Salesforce supports this, you just create a Business Account when that is required and a Person Account when that is required.

But what happens if you created a Person Account and later realized that you needed a Business Account? Many times a prospect will contact you and you don't realize until later in the process that you're working with a business.

Conversion Between these Architectures

Due to the fact that these structures are so different between person accounts and salesforce business accounts, salesforce doesn't provide a way to convert between them. They probably could have provided this functionality, but it would have been difficult to deal with custom objects that may be associated with the contact or the account. The lack of this feature has presented problems to many of my clients over the years.

Custom Development To the Rescue

To handle this limitation we normally put a button on the Person Account page layout for "Convert to Business Account" and on the Business Account Layout for "Convert to Person Account". Then these buttons will call visualforce code that does the appropriate conversion.

The conversion process will literally create a new record of the requested type, then re-associate all child objects/records from the originating account type to the new account type. Then finally, the code will delete the originating record.

This conversion has to be custom to handle your specific customizations. For example, maybe you have 3 Business Account Record Types and 2 Person Account Record Types. In a situation like this, you'll need the visualforce page to ask the user which record type they'd like to convert to. Additionally, if there are custom objects, the conversion has to be written with these particular custom objects in mind.

Need Development in Your Salesforce Org?

So if you're dealing with this specific issue in your salesforce org, or any development issue, and would like to speak to someone here at Snapptraffic Consulting about the development of this system for you, based on your unique customizations, please feel free to contact us. You can reach us through our website at Visualforce Reports

Custom Reports have come a long way in over the years. With the recent addition of report buckets and the ability to do joins between reports, the built in functionality is better than ever.

But with that said - there are still some significant limitations in the Salesforce Custom Report system that need more individualized solutions. The custom reporting system in salesforce is meant to be "universal", meaning, it is designed to meet the various needs of millions of different users. But frequently, a company needs a reporting system designed around their exact process or data model.

Custom Reporting Done in Visualforce

To meet the needs of these clients we usually resort to Visualforce, a system within that allows us to run custom code, written in apex, in the cloud. Visualforce gives us the ability to build "custom user interfaces".

An Example Visualforce Custom Report

Since a report is just a presentation of data. Visualforce gives us all the power to produce the exact custom report that a client might need. When building a custom visualforce based report, we write our code to go get the data needed, assemble it properly, and display it in whatever format is most useful to the end user.

Visualforce Reports
A Custom Report built in Visualforce

See the above example. In that report the client needed to assemble and display data in a way that could not be handled by the standard salesforce reporting system. Here we were able to summarize it as needed, group the dates as needed, compare "Retained" vs "Not Retained", calculate a percentage, and color code the results to make the data easy for the reader to interpret.

Be sure to note: this is entirely custom! I'm not showing you a canned product that we sell or some third party reporting solution. The client, along with a Snapptraffic consultant, discussed the business problem, identified that data upon which a report was needed, discussed the output desired, and our developers wrote the apex code needed to produce the above output.

Drill Downs

Also notice the "Drill Downs" - if you look closely (I know, the image is small), you'll see that many of the numbers in the report are links. Those links open a report that provide the reader with the exact data that makes up the numbers in each cell. The next image is one of those drill downs:

Drill Down on the Exact Data Needed

Here you can see the opportunities that make up one of the numbers in the table above.

Export to Excel

If you look closely at the above image, you'll also see an "Export to Excel" button. This was added at the customer's request and pushes the data in the drill down to an excel file so that they can do further analysis on their own.

Have it your way!

The beauty of using Visualforce to build these reports is that there are so few limitations. Want to email the results? No problem. Push data to excel? You can have it. Compare data from completely independent objects in Salesforce? Easy. Seriously, you can have it your way.

Edit Underlying Data?

How about this interesting use case -  The client wanted to be able to report on progress towards calling goals (they did webinars, look for that word in the example). We created a custom object into which the webinar call goals could be stored. The report became an interface where users could view their progress toward the goal - along with appropriate color coding - and an area where managers could input the goals (only users with appropriate permissions set could edit the goals).

So not only was this a report, it was a goal management system - both reporting on and allowing management of the company webinar calling effort.

Charts? also comes with a powerful dashboarding system, allowing the user to easily create charts in order to display graphically the data contained in an underlying report. It stands to reason though, that if the underlying reporting system has limitations, then so too will the dashboard charts. We get around this using Google Visualizer.

Google has provided a powerful system into which we can feed data, pass certain parameters, and receive back from google the chart requested. Here is an example of that:

Google Visualizer Charts Rendered in Visualforce

Notice the "switches" we provided the user at the top. They can select their regions, display method, and pick their desired date range. Entirely custom, built to meet their needs.

So if you find that your reporting needs go beyond what the Reporting Engine can provide, then reach out to us at

We'd be happy to meet with you, discuss the reports that you need, give you an estimate for having them built, and get them made for you in a timely manner.

Salesforce Scheduled Batch Apex

Scheduled Apex is a super useful system in that permits a developer to write some batch apex code and execute that code at scheduled times. This is incredibly useful because salesforce triggers and workflow rules can only execute as the related record is saved. A salesforce Time Based Workflow rule can fire based on hours or days from some date or time on the record, but its functional capabilities are fairly limited (create tasks, send an email to a limited set of recipients, update a field on the associated record). 

Sometimes you need to take action at some point that is completely independent of the record being saved. A "Scheduled Apex Batch" can solve this problem.

Here is an example: A response is required by a support rep at a given date/time for a case submitted by a client. The "Response Required By" is a time previously calculated, but can't be used by the standard SLA system in SF. Therefore, we need a way to look at all the open cases every few minutes and send notification to the case owner if the Response Required By is about to expire. 

You may also be wondering: "how frequently can I schedule an apex batch to run in" 

A scheduled apex can be scheduled to run at most once every one hour. 

Big HOWEVER; but you can have 12 schedules for the same Apex Class to run every hour. So you can schedule it to execute at the 0 minute of the hour, 5th minute of the hour, ….., 55th minute of the hour. So effectively, the most frequent execution of a given class is "every five minutes".

However there are other limitations that need to be noted:
- Salesforce only adds the process to the queue at the scheduled time. Actual execution may be delayed based on service availability – So, the interval between two subsequent email notifications may be less than 5 minutes.
- You can only have 25 classes scheduled at one time – You will be left with only 13 schedules for other requirements

You may also want to consider the limits on the no. of emails that can be sent per day.

Other Scheduled Batch Apex Application Examples:

- Check all your open opportunities once a day and remind users to update those past their close date
- Find all the open opportunities where there is not an open task for followup and create that task
- Send an email to clients automatically with open balance statements
- Send an email reminder to all clients with whom you have an appointment the following day
- Send an email reminder to all your traveling sales reps every day with a reminder of their upcoming appointments (or send a reminder to them after their appointments to update the opportunity with the results of their meeting with the client)
- Data cleanup: run a batch each day to look for and notify owners of duplicates
- oh, about a thousand others - you can take pretty much any operation you care to on your data stored in salesforce and create other records, make notifications, create tasks, kick off integrations - you name it. 

If you have an idea for a project like this and want to get it developed for your organization, we can help! Our developers produce systems like this every day. Contact us if you'd like to discuss your project, get an estimate, and get it produced. You can reach us at

Producing PDFs from

Producing a PDF from is a need for nearly every client I ever work with. There are countless ways in which being able to produce a PDF will save your users boatloads of time and standardize the client-facing documents your company produces.

Since salesforce does such a good job of organizing your data, say, into Accounts, Contacts, Opportunities, Products, and your custom objects - wouldn't it be valuable to be able to take the data found across all of those records and "merge" it into a PDF? Possibly save that PDF back to the originating record, and then send it to a client?

Typical Uses

While the uses of a PDF are nearly limitless, here are ones that we've done fairly recently:

- Quotes - data from opportunity and quote records sent to your client for their approval
- Purchase Orders - sent to vendors to order product
- Contracts - produced with digital signature anchor tags and sent to client for signature
- Client Invoices - data from salesforce records used to bill the client
- Packing Sheets - an itemized list of items in a shipment
- Payment requests - a statement of open balance
- Print Output - whenever users need to print output from a record, it's convenient to send it first to a PDF.

These PDFs can be generated in almost any way desired. We can generate them from buttons. We can have code that creates them automatically. Sometimes we create custom hyperlink formula fields and put them right on the layout next to other relevant fields (like a "Send Quote" link right under the amount field). Regardless of your need, there is a way to get the document produced.

Visualforce to the Rescue

While there are a few different ways to generate PDFs from salesforce, we typically just write them in visualforce. They simply take the example provided by the client and write code to produce output that looks exactly like it. Our team can typically turn out a standard PDF in about 12 hours of development. Third party apps can help produce PDFs as well, but you'll need some significant time to learn the interface of the application to get it to produce the output you need. Many of our clients have found it more convenient to simply say: "Here is my example document - just make it for me!"

Additional Important Functions for your PDF

Once the document is produced, you'll have to decide what you want to do with it. Normally that will be some combination of the following:
- Open the PDF to the desktop
- Send the PDF attached to an Email
- Store the PDF as Attachment to a record in salesforce
- Send the PDF to a client for a Digital Signature

These are all things that we incorporate in some form or fashion on nearly every PDF development project. The nice thing about custom development - we can include exactly the functions you need. For example, if you need to prepare a Contract PDF, save a copy to the originating Contract record, attach it to an email, call the appropriate Email Template, and send it - this exact process can be executed in one click. A recent project we did creates multiple contracts and prepares them for digital signatures, all in one click, saving the client's reps literally hours during the contracting process.

Sites Page Delivery!

One of the neatest things we've begun doing for people recently is eliminating the need to actually send the PDF as an attachment to an email at all. Now with Salesforce Sites, we can deliver the content straight to the browser. A "Site" is a web page hosted by salesforce. On that page we can display content straight out of your salesforce database in any format we desire.

So lets say you have an opportunity and you want to "deliver" it to your client as a quote. You could make a PDF, like we talk about above, and email it. But you could also just send an email with a link in it, that when clicked opens the quote in a browser window. Rather than open an attachment on an email, they just see the quote in their browser. Here is an example from a recent project where a sites page was used to deliver various quotes.

So hopefully you got a few ideas about  how you can get the PDF you need generated conveniently, straight from If you want some help getting the PDF you need developed. Feel free to reach out to us at Roll-up Summary Fields

Perhaps you've run into a limitation with the Rollup Summary field functionality. While this is an incredibly useful function, roll up summary fields can only be used in very specific architectures.  You must come up with some other way to replace the functionality of a roll up summary field when you don't have the prerequisite architecture or other needs of the system can't permit that architecture. I'll show you below how to get around the limitations.

You should use a rollup summary field when you have a set of child records to a parent record and you want to total some value from those child records.

Roll-up Summary Limitations

Here are a few of the limitations of a roll-up summary field (there are probably others):
- you must be in a master-detail relationship in order to use them
- the field being rolled up cannot be a formula field.
- you can only put 10 roll-up summary fields on an object

So what do you do when you can't comply with one of the above?

Write a trigger!

A trigger can conveniently overcome all of the limitations identified above. (with the one complicating factor being that you can only write a trigger in Enterprise/Platform/Unlimited editions of

To replace the rollup summary functionality, put the trigger on the child object and have it fire whenever a record of that object type is saved. When the trigger is executed, it should collect the value that is to be totaled from the originating record, then go up to the parent object (which now does not need to be in a master-detail relationship), and collect that same value from every other child record. Do the math, then place the result in a custom field on the parent record.

An Example

So for example, imagine a company that uses a Unit custom object (kind of like Products) against their Opportunities to list what clients are buying. They have a Vendor Order record (custom object) also where they order those units from their vendor. The Unit object is child to the Vendor Order object also. So the Unit is the child in a master detail relationship to the Opportunity but in a lookup relationship to the Vendor Order. Unit can't be in a master-detail relationship with Vendor Order because the Vendor Order record doesn't exist when the Units are added to the Opportunity. In master detail relationship, parents must exist before children.

If the unit record contains a Price to the customer, that can be conveniently totaled on the Opportunity using a roll-up summary field. The unit will also have a Vendor Price to record what it costs to buy the unit from the vendor. But a rollup summary field isn't available on the Vendor Order because it isn't in a Master-Detail relationship. So the Vendor Order total price isn't possible via rollup summary field.

By placing a trigger on the Unit object however, we can get our total. That trigger can execute each time the Unit record is saved, then take the Vendor Price from that Unit record, get the Vendor Price from every other Unit record associated with that Vendor Order, do the math, then save that value in the Vendor Order, Vendor Order Total Price field.

Get Help from Snapptraffic Consulting

Obviously, the challenge a typical customer faces is getting the trigger written. You'll need a development environment and someone who knows how to write in APEX. If you don't have those resources available to you. Feel free to contact us, we'd be glad to help. A trigger like the one noted about takes us about 3 hours to produce. (You can find our current rates on our website, noted below). Generally we can have it written within a day or two of your request.

You can reach us at - we'd be glad to listen to any issues you face and help you to get them solved.

Salesforce Web2Anything was kind enough to provide a very simple system for Web-2-Lead (or Web-To-Lead - whatever you prefer to call it). They also have a system for web2case. These are great if you need a really simple method for adding a form to your website which allows you to pass details from forms on your website directly into leads or cases.

But what do you do if you want to do web2opportunity, or web2contact, or web2custom object. There are a few third party form providers which may be able to assist, but what I find works best is a sites page. Sites Pages

A sites page is a web page, hosted by (or more precisely) that interacts with your instance. You can use it to display information contained in your data base (the classic example, used by frequently, being a list of job openings at your company for which you want to allow people to apply).

The domain of one of your sites pages would be You can get one domain, but as many pages as you need.

Showing Data on the Web

The idea here is that you use a sites page to show data to third parties. Another approach that I've used recently is to make customer quotes from an opportunity available to prospects via a sites page - this  technique allows your users to send an e-mail with a link to their quote rather than by setting the quote itself.  The quote is simply presented on the sites page - the system finds the correct quote by details contained in the link.

Receiving Data from a form into

But what about when you want to gather information FROM an individual? We can use Sites there as well. We've done dozens of variations of this, but one interesting application permitted our clients to gather information from the client in preparation for sending a proposal. In that situation, an opportunity was already created, then at an early stage in the process, an email goes out to the client (automatically sent by a workflow rule). That email asks the client to click a link so that they can answer some questions online so that their rep can complete their proposal. The prospect fills out the form, which then submits against their opportunity in salesforce. The link in the email contained the details necessary to "connect" the prospect to the correct form and then the correct opportunity. Another workflow rule notifies that sales rep that the data has been received. Web-To-Anything!

This kind of sites page can be used to gather nearly any kind of data that you care to collect from your prospects and get it into So essentially, they have provided you with a web-2-anything capability. It isn't quite as convenient as the build in web-2-lead, requiring some development - but it immensely more capable.

If you have a need for a sites page, or any apex or visualforce development, please reach out to us - we'd be glad to discuss your sites or development project, quote it, and get it built for you. 

Custom Lookups in

One of the consistent complaints I get by my clients when setting up is the weakness of the standard lookups.

A lookup is how one record in salesforce is "connected" to another. For example, a contact record has a lookup field to the account - the Account Name field. When creating a record, like a contact record, you need to find the correct Account Name, and to do so, you need to use the Account lookup function. That is called using the little magnifying glass to the right of the field.

This works fairly well when you want to search the entire Salesforce database for a certain record, like in the above example, when creating a new contact record from scratch. It is okay in other circumstances too, like when you know the name of the record you want. But these strengths become limitations in other circumstances.

As you can tell from the screenshot above, you have to type in a search term. This can be a drag, especially if you don't know the exact name of the account you're looking for. Even using the wildcard frequently leaves you empty handed. You actually have to leave the page, go find the record you need, then return to the lookup to enter it in.

There are many circumstances when you want the system to provide a "likely" list of records to the user so that they can choose from the ones offerred. Salesforce provides some mechanisms to limit the records returned in the lookup search (custom lookup filters), but these still require the user to know the record that they want to find.

To address this problem, we have developed many solutions over the years to replace the standard lookup functions with custom lookups. These can come in very handy in all kinds of situations: looking up products against opportunities, finding the correct signatory on a contract, finding the right contact for a case. Every solution ends up being unique based on the objects involved and the business model, but there are some common characteristics.

In a recent project, there was an Agreement custom object which had a contact lookup. The agreement record was associated with an Account already and the user would use the standard contact lookup to find a contact and populate a field called "Primary Contact."

We improved on the standard salesforce lookup by adding a new button just above the Primary Contact field.

That button calls a visualforce page (written in apex) that shows the user all the contacts at the account associated with that agreement record. It also gives them the functionality to change the account if needed or create a new contact. In the event there were many contacts at the selected account, we also included a filter whereby the user could type in a search term - our system would filter the list of contacts by seeing if the first name, last name, or title contained that search term.

So all of the user's needs (as determined by the client on this project) were much better met by this custom salesforce lookup than by the standard lookup. They could quickly find the contact that they needed from those at the account they were working with.

If you have a need for a custom salesforce lookup, or any apex or visualforce development, please reach out to us at - we'd be glad to discuss your development project, quote it, and get it built for you.

Dashboards for Platform Users

Here is another issue that can be difficult to figure out.

We have a lot of clients using Platform licenses for many of their users. This is a good deal for a client because they get all the power of Salesforce Enterprise edition for well under half the price. Enterprise Edition is about $125/user/mo. The Platform Edition is a lot less - about $50/user/mo. I've seen people get it for as low as $20/user/mo if they worked a deal with Salesforce.

The limitation of the platform edition is that you don't get the Salesforce "Applications" like the Sales Cloud (Leads & Opportunities), the Marketing system (Campaigns), the Support Cloud (Cases, Assets), etc. So this can be a significant limitation depending on your needs - but for those who don't need those objects, you can save a lot by using custom objects rather than the salesforce standard objects. BTW, you do get Accounts, Contacts, Reports, Dashboards, Chatter, and a whole bunch of the other Enterprise level systems with the Platform such as workflow rules, approvals, the API, full visualforce capability, custom profiles, record types, etc - so it can be a great option if it fits your needs.

But there is one little thing that I kept running into that I finally solved: Platform Users running Dashboards.

In researching this issue I found out that people on the forums simply say: platform users can't use dashboards - BUT THAT ISN'T TRUE!

It's actually pretty simple - if you want a platform user to be able to see a dashboard, the running user must also be a platform user. Simple as that. Make a new dashboard. Set a platform user as the running user. Build your reports and dashboard elements.

If you need help on any issue, feel free to contact me at Our consulting services at Snapptraffic Consulting are geared towards helping the customer get the most out of their system. From troubleshooting to full scale implementation and development - we can help.