Understanding Salesforce URL

Following is the information on the URL structure in Salesforce. I have copied the information as it is from the following 2 posts 
1st post is by Mike Schinkel and second post is by Alessandro
http://thoughtsonsalesforce.com/blog/salesforce/crm/url-structure http://salesforce.phollaio.com/2007/01/11/salesforces_url_structure/

Thanks guys for putting this post, it helped a lot. 

Instances
Salesforce’s organizations reside on multiple instances, to find out what instance you’re on, once you logged into Salesforce, have a look at the address bar; you’ll notice the URL starts with something like:

ssl – North America #0 (aka na0)
na1 – North America #1
na2 – North America #2
na3 – North America #3
na4 – North America #4
na5 – North America #5
emea – Europe, Middle East, Africa
ap – Asia, Pacific
tapp0 – Sandbox #0
tapp1 – Sandbox #1

https://xyz.salesforce.com

where xyz is the name of the instance your organization is on.

Objects’ specific URLs

Every Salesforce’s object has it’s specific URL, here are listed the links to the standard objects:

Objects	URLs	Objects’ code
Accounts	https://[instance].salesforce.com/001/o	001
Contacts	https://[instance].salesforce.com/003/o	003
Leads	https://[instance].salesforce.com/00Q/o	00Q
Cases	https://[instance].salesforce.com/500/o	500
Solutions	https://[instance].salesforce.com/501/o	501
Reports	https://[instance].salesforce.com/00O/o	00O
Opportunities	https://[instance].salesforce.com/006/o	006
Campaigns	https://[instance].salesforce.com/701/o	701
Products	https://[instance].salesforce.com/01t/o	01t

Basic action URLs

Use the following URLs to perform the listed operations on a specific object. Note this is fundamental to then understand how to create internal custom links.

Object’s overview page
https://[instance].salesforce.com/[object]/o
ie: https://emea.salesforce.com/500/o

Create a new record
https://[instance].salesforce.com/[object]/e?retURL=/[object_code]/o
ie: https://emea.salesforce.com/500/e?retURL=/500/o

Edit a record
https://[instance].salesforce.com/[object]/[recordID]/e?retURL=[recordID]
ie: https://emea.salesforce.com/50020000000chRD/e?retURL=/50020000000chRD

Clone a record
https://[instance].salesforce.com/[object]/[recordID]/e?retURL=[recordID]&clone=1

Delete a record
https://[instance].salesforce.com/setup/own/deleteredirect.jsp?delID=[recordID]

where:

• [instance] is the instance’s name your organization resides on;
• [object] is the object’s code;
• [recordID] is the ID of the record itself.

Salesforce.com security model

This is an attempt to help my audience to understand the very basics of the Salesforce.com security model. A clear understanding of the security model is a must for all developers and administrators. At the very least, one should know the types of security and the ways security is enabled/disabled. 

Salesforce.com security is defined at multiple levels. These levels help to share or hide the details with the users. Following are the broad classification of Salesforce.com security model 

1. Object level security
2. Field level security 
3. Record level security

Object Level Security

As the name suggests this level of security is at the object level. You can specify permissions like create, read, update and delete on a particular object(standard and custom). Along with these permissions you can also specify "View All" and "Modify All" permissions. These permissions are often called CRUD permissions. 

This is one of the basic and most important security setting. In Salesforce you specify object level security by using profiles. A profile is a collection of permission and settings, which is used to control access to a particular set of users. For example - you can create a custom profiles for internal users, with only read access, similarly another profile for users who can read and write. 

Use the object level security to provide the basic CRUD access to the users.

Permission	Description	Respects or Overrides Sharing?
Read	Users can only view records of this type.	Respects sharing
Create	Users can read and create records.	Respects sharing
Edit	Users can read and update records.	Respects sharing
Delete	Users can read, edit, and delete records.	Respects sharing
View All	Users can view all records associated with this object, regardless of sharing settings.	Overrides sharing
Modify All	Users can read, edit, delete, transfer, and approve all records associated with this object, regardless of sharing settings. Note “Modify All” on documents allows access to all shared and public folders, but not the ability to edit folder properties or create new folders. To edit folder properties and create new folders, users must have the “Manage Public Documents” permission.	Overrides sharing

I have taken the above table from one of the Saleforce.com help sites. I find this very useful for anyone just starting to learn Salesforce. The third column, represents exceptions to the normal settings. Sharing settings are used to open the default permissions based on some criteria's, for example, give view all to the users in VP role. The sharing settings is a different monster which I will address in a later post. For now, I will stick to the basic security settings to keep this simple. 

Field Level Security
This layer helps the administrator to restrict the access to a specific field to users. These setting will apply to Reports, List Views, Detail and Edit pages, imported data etc. 

Setting Up Field Level Security
To set up field level security (on the edit and detail page), you will need to use a combination of field level security setting and page layout settings. By design the most restrictive setting will trump. For example -  if a field is required in the page layout and read-only in the field-level security settings, the field-level security overrides the page layout and the field will be read-only for the user 
There are two ways to set the field level security

1. Use the field level security section of a profile (Setup > Profile > Objects and Tabs > Field Permissions). This way you can set up field level security for multiple fields in on a single profile

Field Permissions Settings

2. Select the field (for which you want to set permissions) through objects, click on set field level security and make it visible/read only to all the available profiles. 

Record Level Security
This layer enables to you restrict access on records. This layer is very powerful and requires good understanding of the following concepts 

• Sharing Rules/Teams
• Role hierarchy
• Sharing Model/Org Wide Default (OWD)
• Record Ownership's and profiles

I will briefly cover these concepts to give you a better understanding of the model 

Record Ownership's and profiles

This is a basic concept but an important one. The profiles controls the basic access to an object. Without a read access to an object through a profile, you will not be able to see any records related to that object. Profile is the most restricted setting. 

Sharing Model/Org Wide Default (OWD)

The OWD defines the default permissions that users have to view and edit information within Salesforce.com. Each object can have the following sharing model

1. Private

2. Public Read Only

3. Public Read/Write

It is always advisable to start with the most restrictive access and then start working your way up. One should set the OWD first and then plan the other security settings. 

Role hierarchy

The roles enables users to view their own records (obviously :-) ) along with the records of the users under them in the role hierarchy. It also allows a user to edit, change record owner ship of the records owned by users below them.

Sharing Rules/Teams

Sharing rules extend the sharing access so that all data created by users in a certain role or public group is shared with users in another role or public group. One thing to keep in mind, sharing rules are exceptions to OWD and they cannot be stricter than OWD.

For example - lets say there are 2 teams, finance and sales. They want to track customer records for different purposes, however, the records are currently visible to Finance team. You can use a sharing rule to say that all the records owned by Finance are visible to sales team. 

Criteria based sharing rules allows sharing records based on field values in a record. 

Users can manually add sharing rules to grant other users access to records. 

Now, if you consider the record based sharing, the access level opens up as you move from profiles to OWD to Role hierarchy to Sharing rules. I specially like this funnel representation of the access level. I think it may be useful to you guys also, to remember the access level

Record based sharing 

Conclusion
The security model for an organization depends completely on its needs. It may or may not use all the above mentioned settings, however, these settings when combined together provide a solid security implementation. It is always advisable to document your security model before building it, because there are a lot of moving parts which change during a life cycle of a project. If not managed properly the security of the system may be compromised and it can become unmanageable easily. 

I hope you guys like this post!! If you do please share it with others. Keep posting your comments and feedback. Thanks 

Deep clone functionality

There is often a need to copy all the related lists associated with an object. The following example helps to copy the related lists by using an extension. 

Deep Clone

Salesforce provides a clone button by default. This helps to clone the existing record. However, at times there is a need to clone the records along with the related lists. 

The following solution provides a programmatic way using Apex extension to implement Salesforce.com deep clone functionality.

Standard Clone Functionality

Step 1 : Create a visual force page


Create the page with following lines.  Standard controller can be any object. In this example I used Opportunity
 <apex:page standardController="Opportunity" 

    extensions="cloneExtension" 
    action="{!cloneRecord}">
    <apex:pageMessages />
</apex:page>

Note:-
When overriding buttons with a Visualforce page, only Visualforce pages that use the standard controller for the object on which the button appears can be selected. For example, if you want to use a page to override the button on accounts, the page markup must include the standardController="Account" attribute on the <apex:page> tag.
Save this page. 

Step 2: Create the extension

public with sharing class cloneExtension 
{
    //Variable to hold current record
    Opportunity currentRecord;
    
    //Standard constructor method
    public cloneExtension(ApexPages.StandardController controller) 
    {
        currentRecord = (Opportunity)controller.getRecord();
    }
    
    public PageReference cloneRecord()
    {
        //Variable to hold the new record
        Opportunity newRecord;
        Savepoint sp = Database.setSavepoint();
        try
        {
            currentRecord = [Select id, name from Opportunity where id =:currentRecord.id];
            newRecord = currentRecord.clone(false);
            insert newRecord;
            
            //Copy the related list - Test (this is a sample related list I created) 
            List<Test__c> test = new List<Test__c>();
            for( Test__c  testStep : [SELECT Expected_Result__c,Step_Description__c,Step_Number__c FROM  Test__c  WHERE  Test__c =:currentRecord.id])
            {
                 Test__c newTestStep = testStep.clone(false);
                 newTestStep.Test__c = newRecord.id;
                 Test__c.add(newTestStep);
            }
            insert test_case_step;
            
            //Copy related list - Test Case User - Another sample list
            List<Test_Case_User_Join__c> test_Case_User = new List<Test_Case_User_Join__c>();
            for(Test_Case_User_Join__c testCaseUser : [SELECT Id,Status__c,User__c FROM Test_Case_User_Join__c

  WHERE Test_Case__c =:currentRecord.id])
            {
                Test_Case_User_Join__c newTestCaseUser = testCaseUser.clone(false);
                newTestCaseUser.Test_Case__c = newRecord.id;
                test_Case_User.add(newTestCaseUser);
            }
            insert test_Case_User;
            
        }
        catch(Exception e)
        {
            Database.rollback(sp);
            ApexPages.addMessages(e);
            return null;
        }
        return new PageReference('/'+newRecord.id);
    }

}

Step 3 : Override the clone button

Edit Clone Button

Once you click on the override button, you will see the following screen, select the page you created 

Override the button with the visual force page

That's it!

You should be able to clone the related list with any object. Remember that you will have to write the code to copy the related list in the extension. The example above copies only 2 related list. You will have to repeat the code for all your related lists.