Platform Events Developer Guide
j
No Results
Search Tips:
- Please consider misspellings
- Try different search keywords
LoginEvent
LoginEvent tracks the login activity of users who log in to
Salesforce. You can use LoginEvent in a transaction security policy. LoginEvent is
a big object that stores the event data of LoginEventStream. This object is available in API
version 36.0 and later.
Supported Calls
describeSObjects(), query()
Special Access Rules
- Accessing this object requires either the Salesforce Shield or Salesforce Event Monitoring add-on subscription and the View Real-Time Event Monitoring Data user permission.
Fields
| Field | Details |
|---|---|
| AdditionalInfo |
|
| ApiType |
|
| ApiVersion |
|
| Application |
|
| AuthMethodReference |
|
| AuthServiceId |
|
| Browser |
|
| CipherSuite |
|
| City | |
| ClientVersion |
|
| Country | |
| CountryIso |
|
| EvaluationTime |
|
| EventDate |
|
| EventIdentifier |
|
| ForwardedForIp |
|
| HttpMethod |
|
| LoginGeoId |
|
| LoginHistoryId |
|
| LoginKey |
|
| LoginLatitude | |
| LoginLongitude | |
| LoginSubType |
|
| LoginType |
|
| LoginUrl |
|
| NetworkId |
|
| Platform |
|
| PolicyId |
|
| PolicyOutcome |
|
| PostalCode | |
| RelatedEventIdentifier |
|
| RemoteIdentifier |
|
| SessionKey |
|
| SessionLevel |
|
| SourceIp |
|
| Status |
|
| Subdivision | |
| TlsProtocol |
|
| UserId |
|
| Username |
|
| UserType |
|
Working with AdditionalInfo
AdditionalInfo enables you to extend the login event with custom data that can be queried later. For example, you can capture a correlation ID when a user logs in from an external system that shares that unique ID. This process enables tracking logins across systems. To store data with LoginEvent, begin all AdditionalInfo field names with x-sfdc-addinfo-{fieldname}. For example, a valid field assignment is x-sfdc-addinfo-correlation_id = ABC123 where x-sfdc-addinfo-correlation_id is the field name and ABC123 is the field value.
When defining field names, note the following:
- x-sfdc-addinfo- is case-insensitive. x-sfdc-addinfo-{field name} is the same as X-SFDC-ADDINFO-{FIELD NAME}.
- Fields can contain only alphanumeric and “_” (underscore) characters.
- Field names must be from 2 and 29 characters in length, excluding x-sfdc-addinfo-.
- Field names that don’t start with x-sfdc-addinfo- are ignored.
- Field names that contain invalid characters after x-sfdc-addinfo- can cause an HTTP 400 Bad Request error.
- Only the first 30 valid field names are stored in AdditionalInfo. Field names aren’t necessarily stored in the same order in which they were passed to authentication.
When determining field values, keep the following in mind:
- You can’t use existing API field names as AdditionalInfo names in the HTTP header. If the AdditionalInfo name conflicts with an object’s API name, the field value isn’t stored. For example, the HTTP header X-SFDC-ADDINFO-UserId='abc123' doesn’t get stored in AdditionalInfo.
- Additional field values can contain only alphanumeric, “_,” and “-” characters.
- Field values must be 255 characters in length or fewer. If a field value exceeds 255 characters, only the first 255 characters are stored and the rest are truncated.
- Field values that contain invalid characters are saved with a field header of Empty String ("").
- Only the first 30 valid field names are stored in the AdditionalInfo field. They aren’t guaranteed to be stored in the same order that they were passed into the authentication.
- When AggregationFieldName is SourceIp, you can’t filter on AggregationFieldValue if its value is Salesforce.com IP.
How to Pass Additional Information by Using HTTP with cURL
Here’s an example of passing additional information via the command
line.
curl https://yourInstance.salesforce.com/services/oauth2/token -d "grant_type=password" -d
"client_id=3MVG9PhR6g6B7ps4RF_kNPoWSxVQstrazijsE8njPtkpUzVPPffzy8
jIoRE6q9rPznNtlsqbP9ob8kUfMjXXX" -d "client_secret=4180313776440635XXX" -d
"username=user@company.com" -d "password=123456" -H "X-PrettyPrint:1" -H
"x-sfdc-addinfo-correlationid:
d18c5a3f-4fba-47bd-bbf8-6bb9a1786624"How to Pass Additional Information in Java
Here’s an example of passing additional information in
Java.
//adding additional info headers ..
Map<String, String> httpHeaders = new HashMap<String,String>();
httpHeaders.put("x-sfdc-addinfo-fieldname1" /* additional info field*/ ,
"d18c5a3f-4fba-47bd-bbf8-6bb9a1786624" /* value*/);
httpHeaders.put("x-sfdc-addinfo-fieldname2" /* additional info field*/ ,
"d18c5a3f-4fba-47bd-bbf8-6bb9a1786624" /* value*/);
ConnectorConfig config = new ConnectorConfig();
config.setUsername(userId);
config.setPassword(passwd);
config.setAuthEndpoint(authEndPoint);
config.setProxy(proxyHost, proxyPort);
//setting additional info headers
for (Map.Entry<String, String> entry : httpHeaders.entrySet()) {
config.setRequestHeader(entry.getKey(), entry.getValue());
}
// Set the username and password if your proxy must be authenticated
9
LoginEvent
config.setProxyUsername(proxyUsername);
config.setProxyPassword(proxyPassword);
try {
EnterpriseConnection connection = new EnterpriseConnection(config);
// etc.
} catch (ConnectionException ce) {
ce.printStackTrace();
}Standard SOQL Usage
Currently, the only supported SOQL function on LoginEvent is WHERE, and you can only use comparison operators (=,
<, >, <=, and >=) on the final expression in a WHERE clause. The != operator
isn’t supported.
LoginEvent allows filtering over two ordered
fields: EventDate and EventIdentifier.
There’s a catch here; your query doesn’t work unless you use the correct order and
combination of these fields. The following list provides some examples of valid and
invalid queries:
-
Unfiltered
-
Valid—Contains no WHERE clause, so no special rules
apply.
SELECT Application, Browser, EventDate, EventIdentifier, LoginUrl, UserId FROM LoginEvent
-
Valid—Contains no WHERE clause, so no special rules
apply.
-
Filtered on EventDate
-
Valid—You can filter solely on
EventDate, but single filters on other
fields fail. You can also use a comparison operator in this query
type.
SELECT Application, Browser, EventDate, EventIdentifier, LoginUrl, UserId FROM LoginEvent WHERE EventDate<=2014-11-27T14:54:16.000Z -
Valid—You can filter on EventDate
using date
literals.
SELECT Application, Browser, EventDate, EventIdentifier, LoginUrl, UserId FROM LoginEvent WHERE EventDate<=TODAY
-
Valid—You can filter solely on
EventDate, but single filters on other
fields fail. You can also use a comparison operator in this query
type.
-
Filtered on EventDate and
EventIdentifier
-
Valid—Successful queries on LoginEvent filter over
both
fields.
SELECT Application, Browser, EventDate, EventIdentifier, LoginUrl, UserId FROM LoginEvent WHERE EventDate=2014-11-27T14:54:16.000Z and EventIdentifier='f0b28782-1ec2-424c-8d37-8f783e0a3754' -
Invalid—Queries on LoginEvent with EventDate and standard date
literals.
SELECT Application, Browser, EventDate, EventIdentifier, LoginUrl, UserId FROM LoginEvent WHERE EventDate=TODAY and EventIdentifier='f0b28782-1ec2-424c-8d37-8f783e0a3754' -
Invalid—Filtering only on
EventDate with <= or >= operator and
EventIdentifier field isn’t
supported.
SELECT Application, Browser, EventDate, EventIdentifier, LoginUrl, UserId FROM LoginEvent WHERE EventDate<=2014-11-27T14:54:16.000Z and EventIdentifier='f0b28782-1ec2-424c-8d37-8f783e0a3754'
-
Valid—Successful queries on LoginEvent filter over
both
fields.