Apex Code Development You need to sign in to do that
Don't have an account?
KenAllred Is it normal for someone to ask for a login to our SFDC org to help us write an apex trigger?
I had someone reach out and offer to help me with some of the Apex trigger work I've been looking at. The first thing they asked for was a login to our SFDC organization. That surprised me as i wasn't expecting that. If this is normal, I just wanted to get some confirmation. And if they do need access, could i just give them access to our sandbox?
LIving in a world of too many scams has me a little paranoid and I want to make sure I don't make a mistake.
Thanks!
The first method is a username and password. A smart organization would use a separate license, and set them up with a custom profile with only permissions related to editing Apex Code (to prevent them from altering profiles, resetting users password, etc). Not all organizations have a spare license though, so that isn't always practical, but definitely the advised route when practical.
The second route is to clone the necessary items into a separate developer organization, and have them use that. Since developer organizations are free and disposable, and not tied to your current organization in any way, this is a harmless way to give them the tools they need without the access that any organization would be hesitant to hand out. It can complicate redeployment, though, and isn't always possible to pull off. For example, organizations developing extensions for managed packages they do not own, etc, might not be able to use this route.
The third means, which you suggested, is to let them loose in a Sandbox. For added security, it could be a Developer Only sandbox so they are limited to the information they can access as well. This eases deployment, limits the security risk of data exposure/loss/theft, and can be easily recovered in the event that they try to take over the Sandbox. Not all organizations have a spare sandbox, though, so this isn't always possible, either.
The fourth method is unlike the other three, in that it requires no username or password to be exchanged. Unfortunately, it's hard for an average developer to ever have access to this feature, which is a shame, because it is powerful. For this to work, the developer must be an ISV partner, and must have an approved managed package on the AppExchange. Once installed, the organization can use "grant login access" to provide UI access through a login link that will appear in the managed package org. Unfortunately, due to the conditions of being an ISV, not all developers can afford to go through this process, and they have to have a legitimate application on top of it; security team wouldn't just pass a no-component app just for the sake of login access functionality.
In the near future, we'll be able to use OAuth2 to keep connected to organizations that we are developing for. This means that the developer can be given a revocable token that doesn't expose a username or password for the purposes of development. This will help alleviate that concern, since passwords will no longer have the requirement of being exchanged, and without the hassles associated with becoming an ISV/creating a package.
All Answers
When you say reach out and offer to help, is that through the community or is it paid work? If its through these boards that is very unusual - I'd expect people to post responses directly to the boards rather than take it offline.
To give you a yardstick, I've never had access to anyone's org - either production or sandbox - and I have over a thousand solutions to my name.
From a security perspective, I'd never consider giving anyone that wasn't contracted to work for me access to my Salesforce org - while a sandbox may not have customer information I'm pretty sure it has the names, roles and contact information for your staff.
The first method is a username and password. A smart organization would use a separate license, and set them up with a custom profile with only permissions related to editing Apex Code (to prevent them from altering profiles, resetting users password, etc). Not all organizations have a spare license though, so that isn't always practical, but definitely the advised route when practical.
The second route is to clone the necessary items into a separate developer organization, and have them use that. Since developer organizations are free and disposable, and not tied to your current organization in any way, this is a harmless way to give them the tools they need without the access that any organization would be hesitant to hand out. It can complicate redeployment, though, and isn't always possible to pull off. For example, organizations developing extensions for managed packages they do not own, etc, might not be able to use this route.
The third means, which you suggested, is to let them loose in a Sandbox. For added security, it could be a Developer Only sandbox so they are limited to the information they can access as well. This eases deployment, limits the security risk of data exposure/loss/theft, and can be easily recovered in the event that they try to take over the Sandbox. Not all organizations have a spare sandbox, though, so this isn't always possible, either.
The fourth method is unlike the other three, in that it requires no username or password to be exchanged. Unfortunately, it's hard for an average developer to ever have access to this feature, which is a shame, because it is powerful. For this to work, the developer must be an ISV partner, and must have an approved managed package on the AppExchange. Once installed, the organization can use "grant login access" to provide UI access through a login link that will appear in the managed package org. Unfortunately, due to the conditions of being an ISV, not all developers can afford to go through this process, and they have to have a legitimate application on top of it; security team wouldn't just pass a no-component app just for the sake of login access functionality.
In the near future, we'll be able to use OAuth2 to keep connected to organizations that we are developing for. This means that the developer can be given a revocable token that doesn't expose a username or password for the purposes of development. This will help alleviate that concern, since passwords will no longer have the requirement of being exchanged, and without the hassles associated with becoming an ISV/creating a package.
This response was incredibly helpful for me (as a new SFDC admin) on what to expect and the possible solutions I can use if/when I want to give someone access to our specific environment to help us out.
Thank you!