Showing Chatter Pictures without being actively logged in

Written by ShamrockCRM on August 16, 2012 – 1:03 pm

I am developing some PHP code that requires displaying Chatter photos on a web page. The code does not maintain an active browser session with something like OAuth. It simply logs in with the SOAP API, accesses the data, and displays data. Since Chatter photos are stored internal to Salesforce.com and require an active session, this causes an issue. Well, I found a great blog posts that solves this problem. Take a look here if you ever run across this problem.


Tags: , , , , , ,
Posted in API, Chatter, PHP, SOAP | Comments Off on Showing Chatter Pictures without being actively logged in

When and Why to use Territory Management in Salesforce

Written by ShamrockCRM on July 17, 2009 – 10:15 pm

Ok, so in Salesforce.com you have Roles, Profiles, User Records, Sharing Settings, Organization Wide Defaults, Field Level Security, Page Layouts, Lists, Views, Reports, Folders and more to segment, hide or display data in different ways.  Confused yet with this massive interrelation of data management tools?  Well, time to introduce Territory Management into the mix.

Most small organizations might only have the need for a public security structure in Salesforce in which everyone see’s everything and can modify everything.  Fine.

Most medium sized organizations can survive simply with Salesforce profiles, roles and possibly sharing settings.  Great.

What happens when you are managing a Global organization with multiple product divisions, complex sales territories, difficult International legal requirements (German worker’s council, embargoed countries, etc) and varying visibility requirements per Sales Region, Mega Region and Global Regions?  This situation is much more complicated, but entirely doable in Salesforce.com using Roles, Profiles, Territories and Sharing Settings.

Imagine only North America.  Imagine that there are 3 product divisions selling to 5 different sales regions.  The 3 product divisions all sell to the same sales regions, but sell different products.  The product divisions need a Manager/Salesperson management concept within Salesforce.com where the Manager has delete/transfer access for all Salesperson data.  Certain sales people need to be able to cross sell multiple Products within one region.  The reporting structure needs to be done by division (upwards).  Sales people in one sales region should be able to view all Accounts belonging to one region (determined by groups of states), even if they belong to someone else in a different role (possibly managers).

This is a common scenario that can get much more complex in large, International corporations in multi-million dollar Salesforce deployments.

This is how this would be represented in Salesforce:
Roles – Hierarchy of roles represent the Product Divisions.  Each division is broken down into Sales Region roles representing both Managers and Sales People and possibly Sales Partners.  Partners and Sales People both report to the Manager role.  Reporting is primarily done by role, because VP’s/CEO’s for these Product Divisions typically only care about their own sales
Territories –  Hierarchy of territories that represent the Sales Regions.  An example would be: 1 – World, 2 – North America 3 – East N.A..  This can be as granular as necessary.  Rules will be defined that automatically associate Accounts with these territory “buckets.”  So, not East N.A. has a collection of Accounts in East North America that you can assign to any group that you would like.  It is best to provide the minimum sharing capability for these by default.
Sharing Settings –  Sharing Settings are what actually assign Territories to Roles in SFDC.  For example, for the Product Line 1, East North America role, you can assign the Territory and Subordinates for the associated Territory.  This will allow the users in this role to see everything within this region and also cross sell multiple products.  The divisional reporting structure still remains.

Contact me if you would like to know if this could be utilized for your organization.  I have worked with this a lot!


Tags: , , , , , , ,
Posted in Business Analysis, Salesforce.com | 8 Comments »

Salesforce Changes for Delegated Authentication

Written by ShamrockCRM on April 1, 2009 – 9:35 pm

It’s always frustrating when Salesforce changes something in their live product and doesn’t follow through with an update to their developer wiki.  Recently, I had the task of creating a delegated authentication (Single Sign On) deployment for a Fortune 50 company, and was perturbed to discover the sample code was no longer applicable to the production Salesforce.

The provided .NET sample code includes the following code in gotosfdc.aspx:

<form action=”https://www.salesforce.com/login.jsp” METHOD=”POST” name=”sfdc”>
<input type=”hidden” name=”un” runat=”server” id=”username”>
<input type=”hidden” name=”pw” runat=”server” id=”token”>
<input type=”hidden” name=”startURL” runat=”server” id=”startURL”>
<input type=”hidden” name=”logoutURL” runat=”server” id=”logoutURL”>
<input type=”hidden” name=”ssoStartPage” runat=”server” id=”ssoStartPage”>
<input type=”hidden” name=”jse” value=”0″>
<input type=”hidden” name=”rememberUn” value=”1″>
<script language=”Javascript1.2″>
document.aspPostForm.jse.value = 1;
</script>
</form>

This is very close. However, at some point, Salesforce changed their login page parameters.  If you want this sample code to actually work for you, you need to change it to the following:

<form action=”https://www.salesforce.com/login.jsp” METHOD=”POST” name=”sfdc”>
<input type=”hidden” name=”username” runat=”server” id=”username”>
<input type=”hidden” name=”pw” runat=”server” id=”token”>
<input type=”hidden” name=”startURL” runat=”server” id=”startURL”>
<input type=”hidden” name=”logoutURL” runat=”server” id=”logoutURL”>
<input type=”hidden” name=”ssoStartPage” runat=”server” id=”ssoStartPage”>
<input type=”hidden” name=”jse” value=”0″>
<input type=”hidden” name=”rememberUn” value=”1″>
<script language=”Javascript1.2″>
document.aspPostForm.jse.value = 1;
</script>
</form>

Either the login textbox was never called “un” and it’s always been  “username” or they changed it.  I spent a little while scratching my head with this, so hopefully this saves you some debugging time!


Tags: , , , , ,
Posted in Salesforce.com, security | 1 Comment »