Tuesday, June 19, 2012

Monday, June 18, 2012

Workbench Discovered

In typical form, I came across the Salesforce Workbench today while looking for the answer to something completely unrelated.  I was reading a cookbook article on developing a mobile app on the relatively new mobile SDK and saw a reference to this Workbench.  It looks like a lot of familiar capabilities like SOQL/SOSL search, object descriptions, etc.., wrapped up in a clean UI.  One capability struck me right away, that almost every sys admin will want to be aware of, is the ability to SET a user's password.  To the best of my knowledge, there was no other way to SET another user's password.  I'm sure most sys admins out there will appreciate this capability.  Check out the rest of the workbench here:

https://workbench.developerforce.com
http://wiki.developerforce.com/page/Workbench

Friday, May 4, 2012

In the voice of Dr. Evil, "1 Billion records per hour!"

On a Friday night, we did a deployment that involved a data update into Salesforce.  Whilst using the Apex Data Loader utility, I achieved a unprecedented 1 billion records per hour rate from Salesforce!  This is over 300,000 records per second!

Thursday, May 3, 2012

Indexing Delay?

A business user recently showed me that if she created a contact in Salesforce and then searched for that contact, that the contact would not be found.  It was so strange to see this that I opened a case with Salesforce support.  Support recently replied and said that this was expected behavior and that newly created records may not be searchable for up to 30 minutes while indexing is processing!  30 minutes!!

Wednesday, April 18, 2012

Outlook Macro

We use a 3rd party product to integrate Salesforce.com with Outlook.  The client that we use is a add-in for Outlook and for contact integration, it relies on the contact's MessageClass property's value to be "IPM.Contact".  We've seen various products change the MessageClass from IPM.Contact to something else, like IPM.Contact.olTrans (for card scanners).  Blackberry will also change the MessageClass in some cases.  As a result, our add-in is not able to synch certain contacts with Salesforce.com.  To get around this, I created a small macro based on some sources I've seen online to flip the MessageClass and exposed the macro as a button within the Contact ribbon in Outlook 2010.  Below is the source code to change the MessageClass:




Sub Convert2Native()

Dim objApp As Outlook.Application
Dim objNS As NameSpace
Dim objSelection As Outlook.Selection
Dim objItem As ContactItem
Dim debugMode As String
Dim VarFileName As String


Set objApp = CreateObject("Outlook.Application")
Set objNS = objApp.GetNamespace("MAPI")
Set objSelection = objApp.ActiveExplorer.Selection

debugMode = "no"

'setup logging
VarFileName = "C:\OutlookConvert2NativeLog" & "_" & Year(Now) & "_" & Month(Now) & "_" & Day(Now) & "_" & Hour(Now) & Minute(Now) & Second(Now) & ".txt"
Open VarFileName For Append As #2
Print #2, "Opening logging"
 
Print #2, "debugMode = " & debugMode
 
MsgBox "Converting " & objSelection.Count
Print #2, "Converting " & objSelection.Count


If debugMode = "yes" Then
    For Each objItem In objSelection
        If objItem.MessageClass = "IPM.Contact" Then
            Print #2, "Converted Contact " & objItem.LastName & " from MessageClass " & objItem.MessageClass
            objItem.MessageClass = "IPM.Contact.olTrans"
            objItem.Save
        Else
            Print #2, "Did not convert Contact " & objItem.LastName & " from MessageClass " & objItem.MessageClass
        End If
    Next
Else
    For Each objItem In objSelection
        If objItem.MessageClass <> "IPM.Contact" And objItem.MessageClass <> "IPM.Contact.SD.Contact" And objItem.MessageClass <> "IPM.Contact.SD.Contact.Private" Then
            Print #2, "Converted Contact " & objItem.LastName & " from MessageClass " & objItem.MessageClass
            objItem.MessageClass = "IPM.Contact"
            objItem.Save
        Else
            Print #2, "Did not convert Contact " & objItem.LastName & " from MessageClass " & objItem.MessageClass
        End If
    Next
End If

Close #2

End Sub
-------------------
Sources (thank you!):
http://msdn.microsoft.com/en-us/library/ee814736.aspx

http://ideasmiths.wordpress.com/2007/07/17/solution-macro-program-to-change-some-fields-in-outlook-2007-contacts-in-bulk/



Monday, January 9, 2012

Spring 2012

I was thumbing through the Spring 2012 release and for the first time since Chatter was released, I was impressed with the haul of changes.




Here are some highlights coming in early February to a Salesforce instance near you:

Salesforce for Outlook

  • We use a Outlook plug-in that synchronizes Salesforce contacts, events, etc with Salesforce but it is neither Salesforce for Outlook nor Connect for Outlook.  The primary driver for going with a 3rd party's solution was the inability of Salesforce for Outlook users to discriminate between private and public Contacts and tasks/meetings.  Salesforce has finally addressed this shortcoming, over 2 years since the Salesforce for Outlook plug in was released.

Workflows

  • We'll have to see exactly how this works and the limitations around it but one of the potentially more significant changes coming in Spring 12 is the cross-object workflow.  Hopefully, we can avoid the need to write triggers for basic field updates.  Again, this is one that has been in the pipeline for years and glad to see Salesforce finally address it.

Reports

  • It's hilarious to me that Salesforce no longer calls these "reports" but rather has latched onto the buzz around "Analytics".  Whatever it is, they've improved the service markedly.  The most notable improvements to me are the following:
    • You can now run an exception report like "Account without Opportunities".  To do this previously, you almost certainly had to export the results of two different reports into Access, Excel, or SQL Server.  You'll see this tagged in the documentation under "Cross Filters".
    •  The other significant improvement should now allow us to create reports like Opportunities with Activities and Contacts.  Previously, you could have Parent -> Child -> Grandchild, but not Parent -> Child -> Sibling.  Again, we'll see how this actually looks soon, but this is potentially a big improvement.

Apex

  • A couple notable changes for developers to keep an eye on:
    • The number of schedule Apex jobs has been increased from 10 to 25.
    • Test methods can no longer use existing customer data (with the exception of user/profile and record type).  This means all test methods will now need to create new data.  It looks like they've created an exception but for those of us w/ existing non-compliant code, we'll have to do some retrofitting with the "SeeAllData" property.

 

Thursday, December 29, 2011

It is frustrating how difficult it can be to trace down permission-related issues in Salesforce.  Without any clues from the debug log regarding the sharing rules or permissions that are applied when attempting to access/edit a record, the process of elimination in debugging user permissions can be time consuming.

Thank goodness for Google.

We want to allow our sales staff to take ownership of contact records that are created in Salesforce via an integration with our accounting software.  These records, by default, are owned by a system user account, which in our current implementation, does not have a role.

Based on my initial research, I found that there were a couple "nuclear" options:

  1. Give the sales user profile, the permission Modify All for the Contact object
  2. Give the sales user profile, the permission Transfer Records
Neither of these options were appealing to me so I kept searching and finally came across this Salesforce message board:


In one of the posts where a user has paraphrased (I suppose) some documentation somewhere, this blurb got my attention:

  • "Standard Users can transfer ownership of any lead, contact, account, case or opportunity record that he/she owns or that is owned by a user below him/her in the role hierarchy (except campaigns). "

Through some testing, I've confirmed that this would potentially solve our problem, but I am still frustrated with how poor Salesforce's debugging and documentation is when it comes to permissions.  While verifying the statement above regarding the role hierarchy, I came across this official doc:


And of course:
  • "The role hierarchy is not maintained with sharing records. Instead, role hierarchy access is derived at runtime."