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.
If you untick this option, the permissions will be disappeared, even it is selected in Permission Set and has been assigned to users.

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

Users with subscribe report permission will be able to subscribe to reports that the users are able to run (up to 5 reports). Once you subscribe to a report, you will receive email notifications that keep you informed about metrics you care most about, without having to manually open the reports. You can specify criteria/conditions that trigger the 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. Specify if you want to be notified via Salesforce mobile app, Chatter, or email.

With the above explanations, reports that you subscribe to in Classic will not auto-subscribe in Lightning, as they are working in different ways.

Limitations:


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

In Lightning:
  1. Click the "Reports" tab
  2. Click the "All Reports" menu on the left
  3. Click the "Subscribed" header column
  4. You will see all reports you subscribed with a tick in the Subscribed column


In Classic:
  1. Click the "Reports" tab
  2. Click the "All Folders" menu at the left (above the "Unfiled Public Reports" folder)
  3. Select picklist "Items I'm Subscribed to" at the right and "Reports" at the next drop-down
  4. This will filter all reports you subscribed


Last update: 23 Feb 2018


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 Sharing

As per API 39.0, looking at ListView object, we can't retrieve who can access a list view with a 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 the Next button
- Click Retrieve button
- when done click the Download ZIP File link
- extract the zip file
- look for the object folder
- in my case, this is Account object, so open the "Account.object" file with any text editor
- here is the result, you will easily see who has 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:



Deploy change
So for this sample, you work on the Account.object, let's say you remove and add "group" or "role" from sharedTo. To deploy this back to Salesforce, you just need to zip the file back as the same structure as you originally downloaded the zip file.

Open Workbench, navigate to migration | Deploy, and select "Single Package".




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


Last updated: 4-Mar-2019


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




Sunday, May 28, 2017

How to turn off Salesforce mobile app

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



Page-level ad