General Updates
Feed Elements
In API versions 30.0 and earlier, a Chatter feed was a container of feed items. In API version 31.0, the definition of a feed expanded to include new objects that didn’t entirely fit the feed item model. The Chatter feed became a container of feed elements. In API version 32.0, feed elements can be either feed items or generic feed elements. Generic feed elements don’t have an actor property, which means they can be used for system-generated content like the new recommendations in the feed.
| Property | Generic Feed Element | Feed Item |
|---|---|---|
| actor | X | |
| body | X | X |
| capabilities | X | X |
| canShare | X | |
| createdDate | X | X |
| feedElementType | X | X |
| header | X | X |
| id | X | X |
| isDeleteRestricted | X | |
| modifiedDate | X | X |
| originalFeedItem | X | |
| originalFeedItemActor | X | |
| parent | X | X |
| photoUrl | X | |
| relativeCreatedDate | X | X |
| type | X | |
| url | X | X |
| visibility | X |
Important
API version 32.0 introduces new resources that get, search, update, and post feed elements. These resources operate on and return new request and response bodies that represent feed elements. Older resources, request bodies, and response bodies that operate on and represent only feed items aren’t supported in API version 32.0. The documentation for older resources, request bodies, and response bodies contains links to the documentation for the newer resources, request bodies, and response bodies.
Detailed information about these changes are in the following “Feed Elements” sections.
Capabilities
As part of the effort to diversify the feed, pieces of functionality found in feed elements have been broken out into capabilities. Capabilities provide a consistent way to interact with objects in the feed. Instead of inspecting feed item type and using other indirect means to determine which functionality is available for a specific feed element, the capabilities object tells you explicitly what is available. A client should check for the presence of a capability to determine what it can do to a feed element.
| Feed Element Capabilities Property | Type |
|---|---|
| approval | Approval Capability |
| associatedActions | Associated Actions Capability |
| banner | Banner Capability |
| bundle |
|
| canvas | Canvas Capability |
| caseComment | Case Comment Capability |
| chatterLikes | Chatter Likes Capability |
| comments | Comments Capability |
| content | Content Capability |
| dashboardComponentSnapshot | Dashboard Component Snapshot Capability |
| emailMessage | Email Message Capability |
| enhancedLink | Enhanced Link Capability |
| link | Link Capability |
| moderation | Moderation Capability |
| poll | Poll Capability |
| questionAndAnswers | Question and Answers Capability |
| recommendations | Recommendations Capability |
| recordSnapshot | Record Snapshot Capability |
| topics | Topics Capability |
| trackedChanges | Tracked Changes Capability |
In version 32.0 and later, every feed element can have a unique set of capabilities. A capability includes both an indication that a feature is possible and data associated with that feature. If a capability exists on a feed element, that capability is available, even if there isn’t any data associated with the capability yet. For example, if the chatterLikes capability property exists on a feed element (with or without any likes included in the list of likes found in the chatterLikes.page.items property), the context user can like that feed element. If the capability property doesn’t exist on a feed element, it isn’t possible to like that feed element.
Important
In API version 32.0, new resources have been introduced that operate on the capabilities of feed elements. These resources operate on and return new request and response bodies that represent capabilities. Older resources, request bodies, and response bodies are not supported in API version 32.0. In addition, all attachment functionality has been moved into capabilities and attachments are not supported in API version 32.0. Whereas a feed item could have only one attachment, feed items can now have multiple capabilities. The documentation for attachments contains links to the new capabilities.
Detailed information about these changes are in the following “Capabilities” sections.
Recommendations
Recommendations are new to the Chatter feed in API version 32.0.
The news feed in Salesforce1 mobile browser app can include recommendations about useful groups to join. The feed can also recommend the Today app but this option can be turned off from .
Recommendations are generic feed elements with a recommendations capability. They’re an example of what’s possible with the new feed element and capabilities architecture.
Detailed information about these changes are in the following “Recommendations” sections.
Use CORS (Cross-Origin Resource Sharing) to Access Chatter REST API
Note
To enable this feature, contact your Salesforce representative. In API version 32.0, only Chatter REST API supports CORS. REST API does not support CORS.
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.
Chatter REST API supports CORS (cross-origin resource sharing). To access this API from JavaScript in a Web browser, add the origin serving the script to the CORS whitelist.
To add an origin to the CORS whitelist, from Setup, choose . Click New and enter an origin URL pattern.
The origin URL pattern must include HTTPS and a domain name, and may include a port. The wildcard character (*) is supported and must be in front of a second-level domain name. For example, https://*.example.com adds all the subdomains of example.com to the whitelist.
If a browser that supports CORS makes a request to an origin in the Salesforce CORS whitelist, Salesforce returns the origin in the Access-Control-Allow-Origin HTTP header, along with any additional CORS HTTP headers. If the origin is not in the whitelist, Salesforce returns HTTP status code 404.
You must still pass an OAuth token with requests that require it.