Pages

Tuesday, July 25, 2017

Salesforce: Edit Converted Leads

If you have used Salesforce for a quite long time, you may aware that once a Lead is converted, you will not able to view the lead detail, except with report, and will not able edit it, even using API.

But, since Spring '16 Release, a user with special permission will be able to view and even edit the converted lead, directly in Salesforce page. This is a good move, in many cases Sales Ops or super user needs to edit some details in the converted lead.

In the previous blog Set Audit Fields upon Record Creation, we discussed a new permission for user able to populate Create Date, Create By, etc., but a user with the same permission "Set Audit Fields upon Record Creation" will be able to edit a converted lead too.

Thanks to Daniel Peter for pointing a new permission "View and Edit Converted Leads" introduced in Spring '17 Release, this permission reduces "Set Audit Fields upon Record Creation" permission just for the purpose of set audit fields on the record creation. I personally see this is a great approach in separating the permissions, because of the different usage.

Let's see a converted Lead in Classic, even we manually type in the URL, example: https://ap2.salesforce.com/00Q28000002fPqZ, it will be auto redirect to https://ap2.salesforce.com/p/lead/ViewConvertedLead/d?id=00Q28000002fPqZ



But, let's see when a user with "Set Audit Fields upon Record Creation" permission opens the same lead:


This user, able to see and even edit the record from Salesforce page.


Now, let's see what will be happened in Lightning for the same users. For the 1st user without Set Audit Fields upon Record Creation permission, the page will be auto redirect to the converted Contact.



While for the 2nd user with Set Audit Fields upon Record Creation permission, it will stay at the Lead page, so user able to view, and even edit the converted lead.



Editing converted Lead:




Reference:



Monday, July 24, 2017

Salesforce: Set Audit Fields upon Record Creation

More than 3 years ago, I wrote a blog Load Created By, Created Date, Last Modified By, and Last Modified Date (Audit Fields) on how to upload system fields, such as: Created By, Created Date, Last Modified By, and Last Modified Date in Salesforce. Usually, we need to do this as part of the data migration activity, where those fields are also known as Audit Fields in Salesforce.

Since Winter '16, Salesforce introduces a permission called Set Audit Fields upon Record Creation. By default, a standard profile will not have this permission enabled, such as for System Administrator profile, so you have to create a Permission Set with that permission, then assign the users with that Permission Set.

But, if you do not see this permission, navigate to Setup | Customize | User Interface, and look for a checkbox Enable "Set Audit Fields upon Record Creation" and "Update Records with Inactive Owners" User Permissions", make sure this checkbox is checked.

Once you assigned with "Set Audit Fields upon Record Creation" permission, you should see audit fields like CreatedById, CreatedDate in API tools, such as: Data Loader, Workbench, etc.


This is before have "Set Audit Fields upon Record Creation" permission.



This is after have "Set Audit Fields upon Record Creation" permission.




Reference




Friday, July 21, 2017

Salesforce: Subscribe Reports in Classic and Lightning

Image result for report

In Salesforce, users with permission to subscribe report will be able to subscribe reports that user able to run (up to 5 reports). Once you subscribe reports, you will receive notifications that keep you informed about metrics you care most about without having to manually run reports. In Salesforce Classic, you can specify criteria that trigger report notifications.

Subscribe to Get Refreshed Report Results in Lightning Experience
Subscribe yourself and other people to up to 5 reports to receive refreshed report results by email on a schedule that you set: daily, weekly, or monthly.

Subscribe to Get Report Notifications in Salesforce Classic
In Salesforce Classic, Subscribe to a report to receive report notifications periodically when the metrics you care about most meet certain conditions. Set the conditions that trigger notification, and specify if you want to be notified via Salesforce1 notifications, Chatter, or email.

Limitations:

Identify Reports Subscribed
After a while, you will forget which all reports you have been subscribed, follow below steps to identify them:

In Lightning:
  1. Click "Reports" tab
  2. Click "All Reports" menu at the left
  3. Click "Subscribed" header column
  4. You will see all reports you subscribed with tick in Subscribed column
In Classic:
  1. Click "Reports" tab
  2. Click "All Folders" menu at the left (above "Unfiled Public Reports" folder)
  3. Select picklist "Items I'm Subscribed to" at the right and "All Type" the next dropdown
  4. This will filter all reports you subscribed

Reference:


Wednesday, June 28, 2017

Salesforce: Territory Management [1]


Territory management maybe not so popular used by many Salesforce users, but it is out of the box functions from Salesforce and supported by Salesforce. Territory management is not enabled by default in Salesforce, you need to contact Salesforce support to request territory management enable for your organization.

Territory management is an account sharing system that grants access to Accounts (including Opportunities and Cases associated with Account) based on the characteristics of the accounts. It enables your company to structure your Salesforce data and users the same way you structure your sales territories.

At this moment (Summer '17 release), there is 2 type of Territory Management in Salesforce and both are active and supported by Salesforce:
1. Territory Management, aka TM 1.0 (original version)
2.  Enterprise Territory Management, aka TM 2.0 (newer version)


Lightning Support
Territory Management
Original Territory Management appears in the Lightning Experience Setup tree. From there, you can enable, configure, and maintain the feature. Territory information, assignments, and reports are available and viewable in Salesforce Classic only.

Enterprise Territory Management
To set up Enterprise Territory Management, create or update territory assignment models or rules, assign territories to records, or view territory assignments, switch to Salesforce Classic. However, access control on records managed by Enterprise Territory Management settings is respected in Lightning Experience.


Forecast
Territory Management
Territory Management is available only with Customizable Forecasts and is not supported with Collaborative Forecasts. If original Territory Management is enabled, you can no longer use Collaborative Forecasts.

Enterprise Territory Management
Enterprise Territory Management can’t be used with Customizable Forecasts. Enterprise Territory Management and Collaborative Forecasts can both be enabled and used at the same time in your Salesforce organization, but the two features are not currently integrated to work together. Forecast is optional, so you can have TM 2.0 without enabling Collaborative Forecasts.


If you have Territory Management enabled and not sure if you are on Territory Management or Enterprise Territory Management, check this:
1. Territories setup menu
From Classic, navigate to SetupAdminister | Manage Territories, if you see Settings, Territory Types, and Territory Models, you have Enterprise Territory Management enabled. But, if you see Territory Settings and Territory Hierarchy menu, you are using Territory Management.

2. Forecast setup menu
From Classic, navigate to Setup | Customize, if you see Forecasts (Customizable) menu, you have Territory Management enabled. But, if you see Forecast menu, you are using Enterprise Territory Management. If you do not use Forecast at all, you may not see it there.


I'll share further on Territory Management in next blog.


Reference:


Tuesday, May 30, 2017

Salesforce: List View SharedTo

As per API 39.0, looking at ListView object, we can't retrieve who can access a list view with simple SOQL query. But, looking at this metadata API documentation, we can retrieve who can access a list view using sharedTo field. We can use a SOQL query for this, as this is metadata API.

Here is the step by step to retrieve that info, you will need to use Workbench.
Let's say we would like to check who can access a list view called "Account start A".

1. Get the "fullName"
From Workbench:
- select Info | Metadata Types & Components
- select Listview from the dropdown
- click Expand all and find the view name
- if the view is "Visible only to me", you will not find it here


2. Prepare XML file
Copy following XML and save it to a file called "package.xml"
<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>Account.Account_start_A</members>
        <name>ListView</name>
    </types>
    <version>39.0</version>
</Package>

3. Retrieve Package
Open workbench again:
- select migration | Retrieve
- select the XML file prepared in step 2
- tick "Single Package"
- click Next button
- click Retrieve button
- when done click Download ZIP File link
- extract the zip file
- look for object folder
- in my case, this is account object, so open "Account.object" file with any text editor
- here is the result, you will easily see who have access to the view

<?xml version="1.0" encoding="UTF-8"?>
<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
    <listViews>
        <fullName>Account_start_A</fullName>
        <columns>ACCOUNT.NAME</columns>
        <columns>ACCOUNT.SITE</columns>
        <columns>ACCOUNT.ADDRESS1_STATE</columns>
        <columns>ACCOUNT.PHONE1</columns>
        <columns>ACCOUNT.TYPE</columns>
        <columns>CORE.USERS.ALIAS</columns>
        <filterScope>Everything</filterScope>
        <filters>
            <field>ACCOUNT.NAME</field>
            <operation>startsWith</operation>
            <value>A</value>
        </filters>
        <label>Account start A</label>
        <language>en_US</language>
        <sharedTo>
            <group>Coba_Group</group>
            <role>CEO</role>
            <role>CFO</role>
            <role>COO</role>
        </sharedTo>
    </listViews>
</CustomObject>


Let's extend this to retrieve for many list views, modify the package XML file as below:

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>Account.Account_start_A</members>
<members>Account.NewThisWeek</members>
<members>Account.RT_Ke2</members>
        <name>ListView</name>
    </types>
    <version>39.0</version>
</Package>

This is the sample result:
<?xml version="1.0" encoding="UTF-8"?>
<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
    <listViews>
        <fullName>Account_start_A</fullName>
        <columns>ACCOUNT.NAME</columns>
        <columns>ACCOUNT.SITE</columns>
        <columns>ACCOUNT.ADDRESS1_STATE</columns>
        <columns>ACCOUNT.PHONE1</columns>
        <columns>ACCOUNT.TYPE</columns>
        <columns>CORE.USERS.ALIAS</columns>
        <filterScope>Everything</filterScope>
        <filters>
            <field>ACCOUNT.NAME</field>
            <operation>startsWith</operation>
            <value>A</value>
        </filters>
        <label>Account start A</label>
        <language>en_US</language>
        <sharedTo>
            <group>Coba_Group</group>
            <role>CEO</role>
            <role>CFO</role>
            <role>COO</role>
        </sharedTo>
    </listViews>
    <listViews>
        <fullName>NewThisWeek</fullName>
        <columns>ACCOUNT.NAME</columns>
        <columns>ACCOUNT.CREATED_DATE</columns>
        <columns>Record_Type_Name__c</columns>
        <filterScope>Everything</filterScope>
        <filters>
            <field>ACCOUNT.CREATED_DATE</field>
            <operation>equals</operation>
            <value>THIS_WEEK</value>
        </filters>
        <label>New This Week</label>
        <language>en_US</language>
    </listViews>
    <listViews>
        <fullName>RT_Ke2</fullName>
        <columns>ACCOUNT.NAME</columns>
        <columns>ACCOUNT.SITE</columns>
        <columns>ACCOUNT.ADDRESS1_STATE</columns>
        <columns>ACCOUNT.PHONE1</columns>
        <columns>ACCOUNT.TYPE</columns>
        <columns>CORE.USERS.ALIAS</columns>
        <filterScope>Everything</filterScope>
        <filters>
            <field>ACCOUNT.RECORDTYPE</field>
            <operation>equals</operation>
            <value>Account.AccRtKe2</value>
        </filters>
        <label>RT Ke 2 Manual</label>
        <language>en_US</language>
        <sharedTo>
            <group>All_Internal_User_Group</group>                               <roleAndSubordinates>ChannelSalesTeam</roleAndSubordinates>
        </sharedTo>
    </listViews>
</CustomObject>

From the XML returned:
- the 1st view "Account_start_A" is shared to 1 group and 3 roles
- the 2nd view "NewThisWeek" is visible to all users, therefore there is no sharedTo tag
- the 3rd view, "RT_Ke2" is shared to 1 group and 1 role with subordinates.

Let's randomly confirm if the return is correct:



Additional notes:
With REST explorer from Workbench, we can get data of list view, example:
- to get all list view in Account: /services/data/v39.0/sobjects/Account/listviews/

- to get list view data from a list view:
/services/data/v39.0/sobjects/Account/listviews/00B50000008DouiEAC/results

* 00B50000008DouiEAC is ListView ID



Reference:
Metadata API Developer Guide - ListView
Force.com REST API Developer Guide - List Views




Sunday, May 28, 2017

How to turn off Salesforce1?

Salesforce1 app is nice, it gives you access to your Salesforce data and application with no cost and lower effort to configure. But in some organization, it has to be off due to compliance guidelines or security protocols, administrators may be asked to prevent all User from accessing the Salesforce1 platform.



To completely eliminate your Users' ability to access the Salesforce1 interface, you will need to make the following changes:

1. Connected Apps
Navigate to Setup | Apps | Connected Apps | Manage Connected Apps, click Edit link on Salesforce1 for AndroidSalesforce1 for iOS, and Salesforce1 for Windows.

Ensure that the 'Permitted Users' value under 'OAuth policies' is set to 'Admin approved Users are pre-authorized', and click Save.



2. Deactivate from User Profile
Navigate to User Profile and ensure that the 'Salesforce1 for Android', 'Salesforce1 for iOS', and 'Salesforce1 for Windows' permissions are all disabled under the "Connected App Access" section. Once all of these have been disabled, save the changes for the Profile and repeat these steps for all Profiles in your organization.


3. Salesforce1 mobile browser app
To ensure that your Users are not able to access the browser-based version of Salesforce1, navigate to Setup | Apps | Mobile Apps | Salesforce1 Settings. From here, ensure that the 'Enable the Salesforce1 mobile browser app' option is unchecked, and click Save.



Now, let's see what happened when user login to Salesforce1


Next, we need to enable Salesforce1 for a few users to test if Salesforce1 can be approved as the corporate-wide app. There are 2 options:

1. Profile
If all the users are located under the same profile, open the profile and look for Salesforce1 under 'Connected App Access'.

2. Permission Set
This would be more flexible as you can enable it user by users across profiles. Ideally, you should create new Permission Set, click 'Assigned Connected Apps', click Edit button and look for Salesforce1 for... and lastly assign the permission set to the users.



Reference: Salesforce1 - How to Prevent all Users from Accessing the App