Enrico Murru – Page 14

The AccountTeamMember is the record that stores which Users are in the Account Team.

To enable Account Teams click on Setuo > Accounts > Account Teams:

Select which layouts will have the Account Team related lists:

You can now define the roles in your Account Teams:

I’ve added the Customer Support role and also added chart colors (for reports):

Let’s go back to the Account and see the new Account Team related list:

Let’s add a new Team:

The related list slightly changes:

By clicking the Display Access you also see the Account, Opportunity and Case access level for every user defined in the team.

The Add Default Team is related to the UserAccountTeamMember object that stores current User’s default Account Team (users he works with ofter, it is a related list on the User’s layout).

Let’s query the AccountTeamMembers for the given account:

SELECT Id, Account.Name, User.Name, TeamMemberRole from AccountTeamMember where AccountId ='00124000005FoHP'

[Salesforce] The Sobject Crusade: AccountTerritoryAssignmentRule

By Enrico Murru

On April 15, 2016

In Post

Back to the Sobject Crusade list.

Source: AccountTerritoryAssignmentRule

This is an Account assignment rule on territories based on Account fields: Winter ’12 platform release added the new Enterprire Territory Management.

The following doc is a complete guide to setup Territory Management in your org.

This kind of Territory Management needs the Customizable Forecasts, that is an old version of the newest Collaborative Forecat feature, that’s why it is not possibile to simulate a query on this object.

Read this documents:

“Territory Management is available only with Customizable Forecasts and not supported with the Winter ’12 release of Forecasts. If Territory Management is enabled, you can no longer use the Winter ’12 release of Forecasts.”

This is a useful map that shows how object are related in Territory management.

If you have an ORG with this kind of territory management enabled, feel free to write a simple guide on how this object work!

[Salesforce] The Sobject Crusade: AccountTerritorySharingRule

By Enrico Murru

On April 15, 2016

In Post

Back to the Sobject Crusade list.

Source: AccountTerritorySharingRule

Represents the rules for sharing an Account within a Territory.

Unfortunately it is impossibile for me to show you how to use this object because I don’t have a Salesforce ORG with the old Territory Management system, which allowed this kind of assignment rules.

For more details read the AccountTerritoryAssignmentRule blog post.

If you have an ORG with this kind of territory management enabled, feel free to write a simple guide on how this object work!

[Salesforce] The Sobject Crusade: AccountPartner

By Enrico Murru

On April 12, 2016

In Post

Back to the Sobject Crusade list.

Source: AccountPartner

This object links 2 accounts in a partnership relation.

To create a new AccountPartner object, add the Partners related list on the Account object:

Click the New button and add as many Account partners as you want, setting also a role in the partnership:

This action populates the related list:

Note that, on the other Account’s related list, there will be the same relationship but with a different type:

This means that for each partner relationship we’ll have 2 object:

One AccountPartner for the wanted relation (with the specified role type)
One AccountPartner for the reverse relation (with the “reverse” role type)

The reverse value of the role is taken from the PartnerRole object in the ReverseRole field.

The AccountPartner records can be created also in the Opportunity’s Partners related list, and the records will come with the OpportunityId field set and a Primary flag:

That outputs in the related list:

And in the main Account object:

From the SOQL point of view let’s execute the following query:

Select Id, AccountFrom.Name, AccountTo.Name, Opportunity.Name, Role, IsPrimary from AccountPartner Where AccountFromId = ‘00124000003vaBu’ or AccountToId=’00124000003vaBu’

[Salesforce] The Sobject Crusade: AccountShare

By Enrico Murru

On April 12, 2016

In Post

Back to the Sobject Crusade list.

Source: AccountShare

This object allow a User that has access to the record to share the Account object directly to a User or a Group.

To create such object you have to change the Account Sharing Settings to at least “Public Read Only” by clicking on Setp > Security Controls > Sharing Settings:

Now the Sharin button will compare on the Account page layout if you don’t see it, add it with the layout editor):

This page shows all the users, groups, roles and territories that have access to the record.

Let’s manually add a new manual share:

And this is the result (added a group and a user):

The Expand List shows the details of the users to whom the Account is shared:

The SOQL to query the objects:

Select Id, Account.Name, RowCause, UserOrGroup.Id, UserOrGroup.Name, UserOrGroup.Type, AccountAccessLevel  from accountshare where accountid=’00124000005FoHP’

[Salesforce] The Sobject Crusade: AccountTag

By Enrico Murru

On April 12, 2016

In Post

Back to the Sobject Crusade list.

Source: AccountTag

You can tag CRM objects. To enable this feature go to Setup > Customize > Tags > Tag Settings and click the Enable Personal Tags feature:

You can select all the object layouts in which you want to use tagging.

Now you can tag your account object:

Click on Add Tags:

Click Save:

These are Personal Tags, but you can also add Public Tags: to enable this feature, contact Salesforce support.

Once this is done you will have the Tag Manager permission on the profile page, that allow to use public tags that can be used org wide:

Once activated you can select the layout in which to enable Public Tags (edit layout and click on the Layout Properties button):

You can add the tags as you did for the Personal ones:

Let’s query the AccountTag object:

select id, Type, Name From AccountTag Where ItemId = ‘0010000000assQ5’

YOu can enable the sidebar component for the tag search by clicking on Setup > Home > Home Page Layouts, edit your home page layout and select the Tag component:

This components outputs as:

Click on the Tag link of the sidebar component to browse tags:

[Salesforce / Heroku] Salesforce as Identity Provider and Heroku as Service Provider

By Enrico Murru

On April 11, 2016

In Post

One year from my last SSO blog post (Implementing Delegated SSO) I’m still here playing with Single Sign On, this time using SAML 2.0.

For a quick overview of the how SAML works, read SAML FEDERATION FOR DUMMIES and SAML for dummies.

We have 3 actors:

Client: this is your browser
Service Provider: this is the remote Site where you need to access your private data/services without having to log in in this portal (this is Heroku in our demo implementation)
Identity provider: this is the server that hosts your authentication details, which authenticates your private sessions on the Service Provider (this is Salesforce)

These actors speak to eachother to allow the client to be authenticated both in the Service Provider and the Identity Provider.

The aim of this article is to configure Salesforce as an Identity Provider using a NodeJS app hosted on Heroku as Service Provier.

Let’s say we have a Customer Community and every user should access a remote Service Provider without the need to log in again.

First let’s configure a new Community

From Setup > All Communities click on New Community, select the Salesforce Tabs + Visualforce template, select a name:

Click on the Administration tab and then to Members. Leave the System Administrator and add a customer community profile:

Click on Branding to change header image and color theme.

Click on Login & Registration to change header logo of login page and other login/logout settings.

You have setup a new community:

Setup Salesforce as Identity Provider

The next step is to setup Salesforce as Identity Provider.

Enable My Domain from Setup > Domain Managerment > My Domain.

Remember that once the My Domain subdomain is setup you cannot change it anymore.

By deploying the domain you enable it for all your ORG’s users:

Users will be able to login from https://yourdomain.my.salesforce.com/login
if you don’t change the base settings, users will still be able lo login through https:/login.salesforce.com
Integrations will continue to work without any problem

You can even change login brand:

Now go to Setup > Security Controls > Identity Provider click Enable Identity Provider.

Single Sign On is almost here!

For every community and the base Salesforce Identity you are provided with the SAML descriptor to configure Single Sign On on the remote Service Provider.

There is one more step to properly configure the authentication channel.

Create a connected app

From Setup > Create > Apps click on New button of the Connected Apps section.

Fill in the mandatory fields:

Connected App Name: name of your app
API Name: dev name of the app (cannot be changed once set)
Enable SAML: true
Entity Id: this is the unique identifier of your Service Provider. This field is unique across Connected Apps (any other connected app should have a different value)
ACS URL: this is the callback URL on your Service Provider (we’ll be configuring the app in the next chapter)
Subject Type: set to User ID (your user will be identified by its Salesforce ID)
Name ID Format: this is the format of the unique id (urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified)
Issuer: leave the default value

Another cool feature is the Custom Connected App Handler: you can specify an Apex class which is called when the authentication is done.

The class must extend the Auth.ConnectedAppPlugin class:

global class SamlConnectedAppPlugin extends Auth.ConnectedAppPlugin{

    global override boolean authorize(Id userId, Id connectedAppId, boolean isAdminApproved) {
        User u = [select id, First_SAML_Login__c from User where id =: userId].get(0);
        if(u.First_SAML_Login__c == null){
            u.First_SAML_Login__c = System.now();
            try{
                update u;
            }catch(exception e){
                System.debug('Exception:' + e.getMessage());
            }
        }
        return true;
    }


    global override Map customAttributes(Id userId, Map formulaDefinedAttributes) {  
        User u = [select id, Name, CommunityNickname from User where id =: userId];
        formulaDefinedAttributes.put('nickname',u.CommunityNickname);
        formulaDefinedAttributes.put('fullname',u.Name);
        return formulaDefinedAttributes;
    }
}

Where:

authorize(): authorized user based on custom login (e.g. you can query for a given User’s field)
customAttributes(): allow to specify a set of custom attributes to be sent to the Service Provider. In this example the send the user’s full name and nickname
refresh(): (not implemented here) is called upon token refresh (OAuth 2.0)

Configure the Service Provier

The service provider is the external App that provides a service which can be accessed only if the user if authenticated.

It will be using Salesforce as the Identity Provider (don’t you say??).

To simulate the Service Provider, here is a NodeJS app hosted on Heroku:

By clicking the Heroku Button you are redirected to the Heroku app creation:

In the Config Variables lays down the magic:

SAML_ENTRYPOINT: set with the value of the node md:SingleSignOnService Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect” of the SAML descriptor for the community
SAML_ISSUER: set with the name you have setup in the Entity Id of your connected app
SAML_CERT: copy the whole certificate string in the node ds:X509Certificate of the SAML descriptor of your community
SAML_IDENTIFIER_FORMAT: leave with the default value urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
APP_NAME: set a cool name for your service provider
SF_HOME: this is the base URL for your community

Then click the Deploy For Free button and wait for the magic to take place!

Your Heroku app is up and running at https://heroku_app_name.herokuapp.com

Link the Service Provider in your community

Let’s add a simple link to the community sidebar.

Click to Setup > Customize > Home > Custom links:

Create a new Home Page Component:

And add it to a new Home Page Layout tailored to your community:

Let’s test it out!

[Salesforce] The Sobject Crusade: AccountOwnerSharingRule

By Enrico Murru

On April 8, 2016

In Post

Back to the Sobject Crusade list.

Source: AccountOwnerSharingRule

This object allows to manage the sharing rules for account, other than the owner.

When an Account is owned by a User who is related to the group referenced in the GroupId field, than the sharing rule applyes to the User or Group defined in the UserOrGroupId.

You can specify access levels to the Account object and to the main standard related objects: Case, Contact, Opportunity.

N.B. To enable access to this record, you have to contact Salesforce customer support.

This object can be created via GUI in Setup > Security Controle > Sharing Settings:

If you select, on step 2, a Rule Type of type Based on criteria you can also set Account’s fields criteria to decide which groups can share the record:

This kind of configuration is not creatable using the AccountOwnerSharingRule object.

[Salesforce] The Sobject Crusade: AccountHistory

By Enrico Murru

On April 8, 2016

In Post

Back to the Sobject Crusade list.

Source: AccountHistory

This object supports Field Tracking History on the Account object.

To track fields on the Account object, go to Setup > Accounts > Fields and click the Set History Tracking button.

Then click on the Enable Account History flag and select all fields to be tracked:

From now on the selected fields will be tracked in the Account History related list:

Here is the corresponding query:

Select Id, Field, NewValue, OldValue From AccountHistory Where AccountId = '00124000003vaBu'

History tracking has few limitations:

You can track upto 20 standard and custom fields per custom object
The field history data is retained for up to 18 months
Changes to fields with more than 255 characters are tracked as edited, and their old and new values are not recorded
Tracked field values are not automatically translated
Changes to custom field labels that have been translated via the Translation Workbench are shown in the locale of the user viewing the History related list
Changes to date fields, number fields, and standard fields are shown in the locale of the user viewing the History related list
If a trigger causes a change on an object the current user doesn’t have permission to edit, that change is not tracked because field history honors the permissions of the current user
Additional field history increases beyond your current limits require the purchase of the Field Audit Trail add-on, following the Spring ’15 release

[Salesforce] The Sobject Crusade: AccountContactRole

By Enrico Murru

On April 6, 2016

In Post

Back to the Sobject Crusade list.

Source: AccountContactRole

This object defines a role that a given Contact plays on an Account’s opportunity.

There could be only a Primary Contact for every Account.

Add the Contact Roles related list on the Account object.

Click on New, and select a Contact from the CRM, a Role from the picklist and whether he is Primary or not for the Account:

If you select the Primary for another Contact, it will be elected as Primary contact and the other one will be flagged to false.

When Salesforce is life!

Author: Enrico Murru Page 14 of 20

[Salesforce] The Sobject Crusade: AccountTeamMember

[Salesforce] The Sobject Crusade: AccountTerritoryAssignmentRule

[Salesforce] The Sobject Crusade: AccountPartner

[Salesforce] The Sobject Crusade: AccountTag

[Salesforce / Heroku] Salesforce as Identity Provider and Heroku as Service Provider

First let’s configure a new Community

Setup Salesforce as Identity Provider

Create a connected app

Configure the Service Provier

Link the Service Provider in your community

Let’s test it out!

[Salesforce] The Sobject Crusade: AccountHistory

[Salesforce] The Sobject Crusade: AccountContactRole