General Updates to Chatter REST API

Create Action Link Templates to Distribute Action Links in Apps

Create action link templates in Setup so that you can instantiate action link groups with common properties from Chatter REST API or Apex. You can package templates and distribute them to other Salesforce organizations.

Action link templates support binding variables, which are placeholders that allow variable data to be incorporated into action links when they’re created from templates. Specify binding variables in the template and set their values when you instantiate the action link group from the template. For example, use a binding variable for the API version number, a user ID, or an OAuth token.

Action link templates also support context variables, which are placeholders that Salesforce fills in to pass information about the user who executed the action link and the context in which it was invoked to your server-side code.

You can use binding variables and context variables in the Action URL, HTTP Request Body, and HTTP Headers fields of an action link template. After an action link group template is published, you can move binding variables between these fields and you can delete them, but you can’t add new binding variables. You can move, add, and delete context variables in these fields after a template is published. You can also edit any other content in these fields after a template is published, but you can’t edit any other fields.

The workflow for instantiating action links from templates and posting them with a feed element:
  1. Create action link templates.
    1. From Setup, click Create | Action Link Templates and create an Action Link Group template:
      Action Link Group Template Edit page
    2. Every action link group should have at least one action link. Action link group templates and action link templates have a master-detail relationship. Create an action link template:
      Action Link Template Edit page
    3. When you’re done adding action link templates to the action link group template, return to the action link group template and publish it:
      Action Link Group Template published
  2. Make a SOQL query to get the template ID: /services/data/v33.0/query?q=SELECT+id+FROM+ActionLinkGroupTemplate+WHERE+DeveloperName='Doc_Example'.
  3. Make a request to POST /services/data/v33.0/connect/action-link-group-definitions to instantiate an action link group from a template. Specify the template ID and the template bindings (the keys and values for the binding variables) in an Action Link Definition Input request body. The response contains the ID of the newly instantiated action link group, which you’ll associate with a feed item in the next step.
  4. Make a request to POST /services/data/v33.0/chatter/feed-elements. In the Feed Item Input request body, specify the action link group ID to associate the action link with the feed item.
Tip

Tip

For detailed steps, see “Define Action Links in a Template and Post with a Feed Element” in Chatter REST API Developer’s Guide.

Use Action Link Context Variables to Pass Context Information to Server-Side Code

Use context variables to pass information about the user who executed the action link and the context in which it was invoked into the HTTP request made by invoking an action link. You can use context variables in the actionUrl, headers, and requestBody properties of the Action Link Definition Input request body or ConnectApi.ActionLinkDefinitionInput object. You can also use context variables in the Action URL, HTTP Request Body, and HTTP Headers fields of action link templates. You can edit these fields, including adding and removing context variables, after a template is published.

The context variables are:
Context Variable Description
{!actionLinkId} The ID of the action link the user executed.
{!actionLinkGroupId} The ID of the action link group containing the action link the user executed.
{!communityId} The ID of the community in which the user executed the action link. The value for your internal organization is the empty key "000000000000000000".
{!communityUrl} The URL of the community in which the user executed the action link. The value for your internal organization is empty string "".
{!orgId} The ID of the organization in which the user executed the action link.
{!userId} The ID of the user that executed the action link.

For example, suppose you work for a company called Survey Example and you create an app for the Salesforce AppExchange called “Survey Example for Salesforce.” Company A has “Survey Example for Salesforce” installed. Let’s imagine that someone from company A goes to surveyexample.com and makes a survey. Your Survey Example server-side code creates a feed item in Company A’s Salesforce organization with the body text “Take a survey,” and an action link with the label “OK”.

If you include a {!userId} context variable in either the HTTP Request Body or the Action URL for that action link, when a user clicks the action link in the feed, Salesforce sends the ID of the user who clicked.

If you include an {!actionLinkId} context variable in the Survey Example server-side code that creates the action link, Salesforce responds with the ID of the action link and you can save that to your database.

This example includes the {!userId} context variable in the Action URL of the action link template:
Context variables in Action URL field in Setup.
Tip

Tip

Binding variables and context variables can be used in the same field. For example, this action URL contains a binding variable and a context variable: https://www.example.com/{!Bindings.apiVersion}/doSurvey?salesforceUserId={!userId}

Migrate from Action Links Pilot to Generally Available

There are a few new properties in API version 33.0. In addition, some property values have changed. These topics list the changes:

Get Bundled Posts with Aggregated Feed Tracked Changes (Generally Available)

Bundled posts aggregate feed tracked changes made within ten minutes of each other into a single generic feed element so that the feed is easier to read.

For more information on this feature in the Salesforce1 mobile browser app, see See Multiple Record Updates Bundled into One Post.

Bundled posts are returned by requests to resources that represent feed elements in a feed, for example, GET /chatter/feeds/news/me/feed-elements.
Bundled post in Salesforce1
A bundle is a generic feed element with a bundle capability. The bundle layout elements are:
  1. Header—The bundle displays the header of the Generic Feed Element response body. For this bundle, this text is Acme, Corp. was updated.. The time below the header is the relativeCreatedDate property.
  2. Auxiliary Body—The bundle displays the fieldName and the oldValue and newValue properties for the first two Feed Tracked Change response bodies nested in the Tracked Change Bundle Capability of the feed element. If there are more than two feed-tracked changes, the bundle displays a Show All Updates link.

Use CORS (Cross-Origin Resource Sharing) to Access Salesforce Resources from JavaScript

CORS is a W3C recommendation that enables Web browsers to request resources from origins other than their own (cross-origin requests). For example, using CORS, a JavaScript script at https://www.example.com could request a resource from https://www.salesforce.com.

In Spring ‘15, CORS is enabled for all organizations and is also supported by REST API.