Getting started

Getting started.

Every organization should have developed a proper set of documentation to help drive, guide, engage and enable the full potential of a business system such as Salesforce. That does not happen by itself and some organizations decide to start to develop and support a creative process on the road to a ‘successful’ implementation.

Agile, waterfall, prototype, rapid as few samples from the pallet of well-known software implementation methodologies. As there are many more methodologies waterfall is considered the most traditional method elevating the various stages. However, once you have reached the deployment and delivery of the project the business requirements may have been changed due to new insights, business evolution, technological evolution or other factors which requires changes.

It’s key to apply for any given methodology which is suitable for your organization and the controls you require. To assess the best fitted methodology is often underestimated.

Once you have received access to your production org it will be hard to ignore the itch to go for a test drive but please be aware that at some point changes are irreversible so you better start exploring a sandbox org or a free (personal) developer org.  It’s tempting to invite co-workers to the party and to provide access to your brand-new production org but hold on for a minute and you may just start with pollution your system right from the start.

Users within a single Salesforce org (environment) need to be unique across the globe. So, this means that a username can only exist once which may sound naturally however it’s a fundamental thing you need to be aware of.

As salesforce username and email address are two different things. The username must be distinct while the email address is not. This means that you can have two different usernames with the same email address.  Even the username chosen for your production org cannot be used within your sandbox orgs or (personal) development orgs. This calls for a clear convention making sure all usernames are unique, easy to understand and easy to distinguish.

For example, [email protected] as per email address [email protected].

Now this could the basis for any given convention when it comes to naming users. But think about other type of users you grant access to your salesforce org. Partners, resellers, customers, hired staff etc. Using a simple prefix or suffix would make it very easy to identify that Josh Rosa in fact is one of the Certified Salesforce consultants supporting the implementation.[email protected] as username would make it very clear that he is in fact a hired staff and for whatever reason you may consider assigning a different security policy to different types of users.

While touching the subject of polices and standards (conventions) ….  it should be the next vocation to at least draw the outline or concept of various policies and standards. Key to any Salesforce implementation is data visibility. And even when it seems irrelevant as everybody who has been granted access should have visibility to all data it’s good practice to document this as an organizational wide policy together with the constraints for given access.