Saturday, May 05, 2012

A Nimble Introduction to Force.com

Compared to .NET or J2EE, developing on Force.com is both very familiar and very different. It's familiar because you still follow the same-old Software Delivery Lifecycle. You write code, queries, and unit tests using familiar syntaxes and tools. When QA signs-off, you push components from development to production. And when users come up with something that we can do to make their lives easier, we do it all over again.  Of course, there are some notable differences ...

In a brief, 12-page introduction, we walk through how the Force.com platform works, from a developers perspective. [Read More]

Thursday, April 26, 2012

Office Data Silos Considered Harmful


One of the great pleasures we have when rolling out Nimble AMS is rolling up a multitude of Excel Data Silos into a single, shareable, Enterprise database. 

When people learn about Salesforce CRM and Nimble AMS, we find that too many organizations are hamstrung by their current solutions. Customizations are difficult, expensive, and need to be redone whenever there is a significant upgrade. Given such hurdles, it's not surprising that people store important data in one-off Excel worksheets and Word documents, rather than go through the pain of customizing a shared solution. 

Saturday, April 07, 2012

Failing safe with the Apex Data Loader for Salesforce



If you have a way to pull and format data from another system, the Apex Data Loader is a great, on-demand way to push data into Salesforce CRM. Without much effort, you can automate the process and create a hands-free data sync. The tricky part is that while the Data Loader creates excellent logs, there's no obvious way to alert a person when a data sync fails. Once a system is in place, failures are rare, but, in real life, stuff happens, and it's helpful if failsafes are in place. 

A key problem is that the Apex Data Loader writes an error log whether there are errors or not. If the pass is 100% successful, the error log will have a header line and no rows. 

If the error log was only written when errors occurred, we could just look for the error logs, and process the files whenever they crop up. But, in this case, we first need to look inside the log and count the lines before we can be sure there was a failure.