enabling email on records in lex is not what i imagined spending much time on in our migration…but here we are.

if you are in a sandbox, deliverability must be set to all email, else the action wont show up on any records period.

you need to add the sendemail action to the global publisher layouts, or override the specific page layouts to include it. makes sense.

per this doc, the send email action only works in lex but must be in the classic actions section also. some mumbo jumbo about inheritance. just tested and indeed it is the way. just dont ask.

once you finally get it to show up on the page, you may get a big red error message when you try to actually use it. has happened to me more than once! try disabling and re-enabling enhanced email per this thread on success. again, just dont ask.

you can indeed customize the layout for the email action. I removed...

the documentation on this spring20 feature is so bad its almost like the feature doesn’t exist at all.

this is all you get - one example and 2 notes

some missing ‘details’

a) date fields need to be converted to string using the TEXT formula

b) you can pass RecordTypeId (case sensitive) via a separate url parameter, but not in the default field values. the docs just say its not supported yet and strange things may happen. what is the point of having this feature without supporting record types? insert snide remark about confetti here.

example

/lightning/o/Opportunity/new?recordTypeId=012400000009dr3&defaultFieldValues=...\

c) the nooverride=1 parameter works in lex. if you have overridden the ‘new’ button on the object with say a visualforce page for example so people can only create opps from contacts or accounts, you can pass nooveride=1 and it will let you bypass that...

cleaning up our integration user, and found a large number of logins from a mysterious application named “Expresiv” with an AWS IP address.

a few posts on salesforce forums over the years, mostly very old

i had a hunch, that turned out to be correct, that in my case these came from old formassembly forms that were connected via basic auth (un / pwd / token) instead of the new (c 2014) oauth option.

so now i gotta track these down and update them bc basic auth is no bueno.

the UserRecordAccess object “Represents a user’s access to a set of records”.

in apex, you can query this object to determine if a user can view, edit, delete, share, or transfer a record.

SELECT RecordId, HasReadAccess, HasTransferAccess, MaxAccessLevel
FROM UserRecordAccess
WHERE UserId = [single ID]
AND RecordId = [single ID]

in flow, you can query this object to test for edit before updates, in theory, but its got some quirks because it has very specific requirements around how the query is structured, and the standard flow “get records” element does not meet them.

the docs specify these requirements for the query. the 2nd and 3rd ones come into play here.

SOQL restrictions:

• When the running user is querying a user’s access to a set of records, records that the running user does not have read access to are filtered out of the results.
• When filtering by UserId...

in setup - session management, you can filter to see session where
SessionType = UI
ParentSessionId = null

and those are your currently logged in users.

i needed to track that over time, to see what our numbers look like for internal purposes.

i wanted to track this every 30 mins, to capture spikes. we have session length set to 2 hours, so that clears out inactive sessions reasonably fast.

so via flow i could get records of the authSession object, but scheduled flows are max 1x/day, without hackery. didnt want to write any code for this, so went to power automate.

was very easy to setup a get records to query salesforce, and then write the number of simultaneously logged in users to an excel online file. and power automate lets you schedule to run very frequently, even in seconds. so every 30 mins is no issue.

and…voila

The standard sharing button and change owner button are great for hierarchical organizations, as the ‘power’ magically flows up the role hierarchy - so bigger fish higher up the role hierarchy can change owner / share records of all the little fish underneath them.

this is not so great when there is a high degree of collaboration within roles. in my case, each role represents a country office and country offices are collaborative entities. anyone in the country office should be empowered to change the owner of a contact owned by anyone else in the office, without asking the current owner.

while the standard ‘change owner’ functionality is carved in stone cannot be overridden, you can add a custom button and a flow in system mode that allows for alternative models like this.

its quite simple. the flow runs in system mode. it checks if $user.role = owner.role, and if so, lets them...

sorry the images turned out huge and this article is hard to read

if you reference a screen multi-select choice element in a formula, the formula uses the choice label, not the choice value.

choice with value defined

choice is used in screen multiselect checkbox group :

formula field references screen field

output uses choice labels

but, if you first assign the screen field to a variable, and use the variable in the formula, then you get the values.

assign screen field to variable

formula uses variable

output uses choice values

feature or bug…you decide!

Email to case matches on all email fields, including custom email fields.

However, if email to case finds a matching contact, the auto-response email appears to always include the contact’s preferred email, which is problematic if one thinks about it for a few nanoseconds. Contact submits a case from email abc and the autoresponse is sent to email xyz (and also email abc, if you check the box to copy all email addresses on the autoresponse).

There is now an easy declarative way to remove the contact from the case, using before-save flows, which fires before the auto-response rule!

The flow needs to set case.contactId and case.preferredEmail to blank (global constant empty string). I assume both are required, did not test them independently.

i just spent an hour trying to get an import file working, because translation workbench…

the documentation ON THE IMPORT PAGE says

Include the language attribute at the top of the file. Your format should look like Language = “en_US” and include a valid language reference.

proof:

Nice, if it was true, but its complete fabrication. It makes not a single iota of difference if it is there or not or filled with garbage.

What is required, is the following

Language code: [valid language code]
Type: [source | bilingual | data]

I spent a freaking hour trying to do shit with Language = xyz, making sure my file is utf8 etc etc etc. What garbage.

So this worked fine

Language = "dumpsterfire"
Language code: es
Type: Source

 KEY   LABEL

CustomLabel.FD_GAR  I am a Sucker

In Summer 14, Salesforce added the isSandbox boolean field to the Organization object that can be easily queried in apex.

In flow, process builder, and workflow rules, you can access the $organization global variable via a formula field, but a number of fields are missing, including isSandbox

You might think you could hard code the org Id but it wont work, due to magical mysterious things that happen in the sandbox refresh engine, which will update almost all references to the new sandbox org id.

In flow, it is quite easy however to get this info via a get record element. Do a get records on the Organization object (all records), then you can access the isSandbox field, and evaluate it in a decision element.

Get Records

Decision Element

Sadly, this is not available for process builder or workflow rules and my idea for this only has 3 votes in two years, flow is the future…

...