If you are using the latest Force.com IDE to develop s-controls or Apex code, you know how nice the latest upgrades are — for editing code, testing, and staying in sych with Salesforce.

I’ve just discovered something else really great — you can edit metadata for objects and fields in your Salesforce instance.  (It has to be a sandbox or developer instance, but you can then package and "deploy" your changes to a production instance.)

Have a custom object or a picklist in one instance and want to copy it to another?  Need to change a bunch of field names or picklist values?  You no longer need to package the items and install them from the appexchange, or go through all the pointing and clicking.  Instead, you make the changes in the object metadata XML files in Eclipse — you can use the XML design tools, or just edit the raw XML:

At first, I was getting a lot of errors when saving objects.  There is a bug, and I found the workaround here.  Basically, there is this file called package.xml — if you are adding an entirely new object (via the New menu), the Force.com IDE updates that file with your additions.  But if you just add custom fields, or if you copy and paste anything from one instance to another, it won’t be in package.xml, so you’ll get an error when saving or synchronizing to Salesforce. 

The trick is to open up package.xml, find or create the section that lists the type of thing you want to create, add the tags, save package.xml, and THEN save your new items.  For example, putting this code in package.xml lets me add the three custom fields shown in the Lead.object file above:

   
        Lead.Address_Type__c
        Lead.Birthdate__c
        Lead.Communication_Preference__c
        CustomField
   
Be sure to add the code to package.xml before EACH thing you add/paste and save, because Salesforce synchronizes package.xml when you save, taking out any entries that aren’t actually in your instance.

At NPower, we’ve been making increasing use of Apex code to do some things we could not do before:

• enforcing business rules across objects
• updating records automatically across objects
• rolling up data like membership renewal date and contact donation totals 
• separating the web interface of s-controls from the code that actually modifies data

All great stuff!  And we love creating and testing Apex code (and s-controls) in Eclipse.  The latest release is really slick (more on that in another post).  But what we really wanted when this was all done was to give a consultant or a client a link where they could install this code into their own production instance of Salesforce.

Until this week, I thought the only way to install Apex code was to create a sandbox or developer account that exactly mirrors the account you want to install into, create and test all the code, and then deploy.  But I found out we can now package all this up into an AppExchange download.

I tried this out yesterday with a large package of apex, s-controls, custom fields, reports, and so on. The Apex code installed, tested, and deployed directly from the package link.

This will be a big timesaver for us — and in the long run, I hope it will make it possible for us to create powerful tools that clients can install with very little help from us.

Now all we need is the ability to package page layouts on standard objects.

Here are a few tips we are sharing with our clients about keeping their CRM instances safe and secure. This is mostly targeted at organizations that are currently using the Salesforce platform.

We can broadly break up this topic into three areas:

Physical Security

Machine Access – If you or your staff operate in a fairly public environment where their machines could easily be accessed by others, you need to take extreme care to ensure that your users logout whenever they are away from their machines. Since it is likely that Users will forget to logout it would be prudent to setup a frequent Session Timeout. You can do this in Salesforce by going to Setup –> Security Controls –> Session Settings. We would recommend the 30 minute timeout for anyone who operates in a public or semi-public space.

Written Passwords – Ensure that your users are not writing their username and password on a sheet of paper which is next to their computer. We have witnessed this many times and it defeats even the best security measures!

Digital Security

Strong Passwords – We recommend that you set your password policy so that at least 8 characters are required with a mix of alpha and numeric. Never allow the password to be used as a part of the username or the security question. To manage password policies in Salesforce go to Setup –> Security Controls –> Password Policies.

Password Expiration – We recommend you have your passwords expire at least once every 90 days and more frequently if you organization can handle it. Please note that if you have external applications (such as a website) which interface with your CRM, you will also need to reset these passwords when they expire.

Disable Accounts – Don’t forget to disable accounts for former employees and consultants who may have been on the system in the past.

Audit Your Login History – Check out who is logging into your CRM instance by viewing the Login History or User Adoption Dashboards. You may even want to setup a report that you can check on a periodic basis.

Recovery

Backup Your Data – Please backup your data! If you are a Salesforce user, you can backup your data for free every week. Simply go to Setup –> Data Mgt –> Data Export. If your data changes so frequently that a weekly backup is insufficient, consider using a product such as Demand Tools or get an ODBC Driver which allow you to connect to your CRM and download all data on a more frequent basis.

Following the above tips should leave you in pretty good shape for your CRM security. Also, please be sure to read any security bulletins which your CRM vendor sends to you and alert your users to any new threats as they arise.

Some time ago, I had a client who needed an easy way for inexperienced users to filter a report, on a regular basis, based on several different criteria.  In Salesforce, anyone can filter a report like this, but it takes a couple dozen clicks and a bunch of typing.  I wrote a simple s-control that allowed users to filter the report in a really simple interface.

When the user selects values and then clicks Search, the Javascript code builds a long URL that tells Salesforce to open the report and apply all the selected filters - something like this:

https://na3.salesforce.com/00O50000001QCuS?pc2=00N50000001JsTx&pn2=eq&
pv2=American%20Sign%20Language&pc4=00N50000001JsUX&pn4=in&pv4=Immunizations&
pc5=00N50000001JvOE&pn5=in&pv5=North%20End& pc6=00N50000001JvNO&pn6=eq&pv6=1

I showed my s-control to Drew Piston at a Salesforce event last year, and it turns out he was hoping to do something similar for his group at the Bay Area Chapter of Red Cross.  This week, he posted a Jing screencast that shows his version of the s-control in action.

Thanks Drew!