Pages

Showing posts with label requirements. Show all posts
Showing posts with label requirements. Show all posts

Oct 4, 2012

Smarsh Launches Compliance Archiving for Salesforce Chatter

How can the explosion in social media communications conform to compliance requirements? Compliance solution provider Smarsh has launched Archiving & Compliance for Salesforce Chatter, that might just make it a little easier for companies to meet those standards.

The service, offered on Salesforce.com’s AppExchange marketplace, allows organizations to capture, preserve or search Chatter files, so that they can be used for compliance, recordkeeping and e-Discovery initiatives.

Uses Salesforce Platform

The Portland, Oregon-based Smarsh offers hosted solutions for archiving electronic communications for compliance and record retention. The archived communications include email, IMs and such social media platforms as Facebook, LinkedIn, Twitter and now Chatter. Founded in 2001, the company was originally a financial technology solutions and consulting company that turned to email archiving as financial firms had to meet regulatory mandates from federal agencies.

The Archiving & Compliance service for Chatter is built on Salesforce’s cloud-based app platform. All data can be captured in real-time, thus minimizing the risk of lost data from the communication streams, and the service also archives Chatter attachments. Customers are not charged for storage or disk space.

Communication is stored in non-erasable, non-rewriteable media (write once, read many optical storage) in the native format, it’s available worldwide through the Web-based Smarsh Management Console, and it’s redundantly preserved in geographically-dispersed data centers.

Review Hierarchy

Search can be conducted across all objects in the Chatter communities, and results allow searchers to review communication threads. Repeated searches can be saved, and searches can be customized with company-approved lexicons of keywords or phrases — or Smarsh’s default list can be used.

There’s also a permission-based review hierarchy, which can be structured so that it emulates the review structure of a given organization. Message supervision roles can be assigned to specific users and groups with appropriate access and functionalities, and temporary permissions or access can be granted, such as for outside legal counsel. Every administrator session and action is documented.

Messages can be annotated, flagged or escalated, and those actions themselves become searchable. A Reporting Center provides analytics reports on usage, system audit history and message archive data, and message data can be exported in the EDRM XML Interchange Format Schema or other popular e-Discovery vendor “load file” formats.
 

 
 

Source : cmswire[dot]com

Aug 21, 2012

A Little Birdie Told me Twitter was Doing Product Strategy via API

Late last week, Twitter announced a series of API changes that it plans to launch in the upcoming weeks. The changes covered several different areas including changes to authentication requirements, changes to number of calls an end-point can make to Twitter in an hour (both up and down) and creating a series of binding agreements that developers and applications must adhere to. While the API will be released shortly, developers will have a migration period of 6 months before the old API is retired.

We Are The Knights Who Say Tweet!

While the individual changes themselves are indeed interesting, the fun stuff lies just beyond the surface in what the changes mean to both Twitter's business strategy and to its overall approach to product strategy and development as well. These changes are not random demands for "shrubberies" but rather a fully acknowledged attempt to encourage and discourage specific partner and developer behaviors when integrating with and leveraging Twitter's platform. In other words, Twitter has fully embraced the idea that its API is a product to be designed for a specific set of consumers along with a specific strategy in mind (something predicted in these pages earlier this year).

Twitter is still in the throes of figuring out how to fully monetize its immensely popular micro-blogging platform and has made these changes with an eye towards furthering its profitability goals. By throttling smaller apps and unleashing larger ones, twitter has furthered its ability to charge enterprise media partners for access to the firehose of tweets in search results and also for trending topics.

The authentication, partnering and rate limiting changes will directly go after data scrapers in two ways (also predicted in these pages earlier this year):

  1. The lower rate limit (more than five times less than its current amount) will make it harder to do mass scraping and will force any programmatic scrapers to identify themselves with a license key.
  2. The upper rate limit (just over twice the currently supported amount) will give scrapers a legitimate opportunity to abandon scraping and legitimize their use of twitter data.

No One Expects The Twitter Inquisition!

Another big shift is Twitter's move from display guidelines to display requirements along with a certification requirement for certain Twitter apps. Twitter will now require its developers to adhere to a specific set of rules to standardize appearance and functionality. Twitter has justified this change by citing that it will give a better, and more standard, interface to its end users and has reserved the right to revoke license keys from any non-conformists. Some developers have cried foul citing that this will limit the individual Twitter-client developers ability to differentiate their user experience and their overall ability to make money. Well duh! Twitter basically said that in its blog post by specifically saying that it was trying to discourage developers from making new differentiated client apps for consumers.

In case it is not obvious to the solo developer community, Twitter really does not care whether you make money. Twitter cares whether Twitter makes money. In order for Twitter to make money, Twitter needs consumers to engage with Twitter on the Twitter site as much as possible. Twitter's value prop to developers is a free, functional and highly available micro-bloging platform that can easily be integrated into your site. If that is not good enough, build and market your own platform and see how much money that makes you.

 

Continue reading this article:

 
 

Source : cmswire[dot]com