11

I'm a long time Salesforce user brought into a company that is very much traditional SDLC with legacy home built systems. I am trying to get them to understand that a Salesforce developer must have access to production (Not kosher in traditional SDLC because they have too much power). I've explained that there is an audit trail (only 6 months, but we can download periodically) as well as change sets (again only live for 6 months, shows all pieces changed). They need more than a year of audit records for compliance purposes (so they've stated).

This isn't the first public institution I've worked for; however, it's the first that has been in this state of transition. I was wondering if anyone has any additional recommendations on ways that I can educate the business that SFDC does not exactly fit into traditional SDLC. For example, I think I'm finally getting across to them that there isn't a concept of Builds in SFDC (I had a QA person read me the riot act for adding a custom field to a page layout because I wasn't authorized to do a new build sigh).

Does anyone have any insite that they can provide or better yet any white papers that aren't from consulting agencies trying to sell us on why they're the best to "help us" become SOX complaint by paying them a truck load of money?

Improve this question
1
  • How would you argue SFDC that Salesforce should different than other apps for SOX? Anything touching financials in a public company is tightly regulated; why should this app be different?
    – Mike Chale
    Commented Jul 22, 2014 at 1:34

3 Answers 3

Reset to default
4

Technically a developer doesn't need access to production (or could be demoted to some "view all, readonly" Profile if he has to see some data). You could be packaging up changesets from your sandbox, sending them upstream and then authorized admin validates & deploys to test, later - to production...

Similarly if you use Metadata API (Eclipse etc) - you could be publishing zipped files for them and they could use Ant (yeah right) or maybe the Workbench to deploy them. If they're very paranoid they could host a local copy of Workbench.

It is pain and you need to ask somebody to click the magic link every time you need a sandbox refresh but well, if that's how they want to have it secured...

Re: change tracking.

You can download audit trails.

You can use version control system (Subversion & Git are best suited for Salesforce in my opinion; Visual Source Safe and IBM ClearCase are worst because they demand explicit checking out the file(s) before changing and most of the time you don't know what will happen when you hit "refresh from server"... Well, you could lock whole project down I guess and annoy your fellow devs).

Bear in mind that class file doesn't say who modified it last. You could use it for change tracking & backups but you still need either the audit trails or periodical querying of tables like ApexPage.

Last but not least there are few tools that make periodic snapshot of metadata and push it to another cloud (Heroku, Amazon Web Services etc) - you could use these or quickly whip something similar with Ant. I've heard some good stuff about "Panaya for Salesforce" (I'm not related to them and I'm not a client). No idea if it's just a searchable backup or can it somehow report on who changed what. I somehow doubt it, I don't think audit trail is exposed in any API so that'd require some screen-scraping.

Improve this answer
2
  • I'm not just the a developer, I'm also an admin for the org (title is developer/admin), and our change management folks aren't trained on SFDC and it's darn scary for someone who isn't familiar with SFDC doing prod changes. The plan is to use mercurial for version control for pushes into the full sandbox. I'll take a look at the metadata snapshots, it's an interesting idea.
    – Jason Hardy
    Commented Jul 21, 2014 at 21:31
  • I've written it from contractor point of view, at my current client I've been starting from "access to dev sandbox only" position and I guess either I've gained some trust or it became too cumbersome for the client to approve every action. Still the point about changesets / version control holds. There's only a handful of actions that you can't that way (say enabling Chatter). So it's really up to them how far they want to go. And I've also met some "cowboy coders/admins" who complained when I've overwritten their page layout change they didn't bother to replicate in sandboxes...
    – eyescream
    Commented Jul 21, 2014 at 22:31
0

A version control system, such as Github, is sufficient in many cases for showing metadata change history.

A Developer can have access to Salesforce, but the deployments should be done by an Administrator via change set or ant deploy. That's just a good separation of concerns that demonstrates to auditors that someone reviewed and accepted the changes.

The Case object is very useful for conducting a Change Approval Board (CAB) with demonstrated history of review and approval.

For access control and usage related compliance reporting there's a solution by http://www.logalytics.io for Salesforce (note: I am involved with this company).

Many organizations are successfully able to keep Salesforce out of scope for SOX compliance if it can be demonstrated that SFDC is not being used for reporting financials.

SOX compliance is really more about process than anything else.

Some blog articles I've written related to Salesforce development process and compliance:

http://www.embracingthecloud.com/2010/11/21/SalesforceChangeManagementMatrix.aspx http://www.embracingthecloud.com/2011/02/26/ForceMigrationToolVsChangeSets.aspx http://www.embracingthecloud.com/2011/08/21/SalesforceAtFacebookDreamforce11.aspx http://www.embracingthecloud.com/2013/11/18/LogalyticsForSalesforce1DreamforceMobileHackathon.aspx

Hope this helps!

Improve this answer
0

Although I still don't have admin access in prod; however, we are in the process of implementing DreamFactory to help with the audit trail and deployments. With the use of DreamFactory, we should be able to more easily test deployments before pushing into production. The ability to re-use snapshots across environments should also help alleviate a lot of the apprehension that I had about not having admin access in production.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .