SAP buys ARIBA for 4.3 billion dollar

SAP subsidiary, SAP america has entered into an agreement to purchase the cloud based business commerce network ARIBA for approximately 4.3 billion dollar. This gives ARIBA a valuation of $45 per share, 20% more than the current stock price. 

SAP has been strengthening its cloud based solutions to cater to the emerging markets in cloud and to compete with Oracle and Salesforce.com. Recently SAP acquired SuccessFactors for over 3 billion dollar. 

SAP also recently announced the roadmap for its cloud applications business  focusing on managing customers, suppliers, employees, and financials, in addition to its cloud suite offerings SAP Business ByDesign and SAP Business One.

Oracle  acquired RightNow and Taleo. The cloud computing market is buzzing with activity and these recent acquisitions have validated the other cloud players. This in some way indicates that the on premise ERP (enterprise resource planning) is nearing an end in near future if not immediately. 

Here are my 2 cents on the recent buying spree from Oracle and SAP 

If both the companies continue to grow inorganically into cloud market without any real innovative ideas they may be left behind. These strategy will only vindicate the innovative players like Workday and Salesforce.com. Oracle and SAP cannot become major cloud players by just buying out cloud companies. They have to come up with innovative solutions like relational database on cloud, online ERP system etc. 

ARIBA 
The company is headquartered in Sunnyvale, California, with approximately 2,500 employees. The company provides a system for suppliers to provide the catalogs and the buyers to buy the products over the cloud.  More than a million transaction are handled by ARIBA with values in billion dollar in a month. Other products like spend management, discount management are also provided. 

SuccessFactors
The company is headquartered in San Mateo, California. It provides employee performance management over the cloud and has over 3000 customers with million of users  in over 180 countries. 

Taleo
The company is headquartered in Dublin california, with over 5000 customers. It provides talent management over the cloud. 

RightNow
The company is headquartered in Bozeman, Montana. It provides CRM solutions and has over 1000 employees. 

Big set back for Salesforce.com

IBM who implemented the single biggest implementation of Siebel CRM in the world has decided to do away with it. Siebel is a subsidiary of Oracle. Good news is that it has decided to go with a cloud solution. The bad news atleast for Salesforce.com is that  it did not win the contract. 

This is what it means for the industry 

1. Cloud is a mainstream option and here to stay. It further emphasizes that world's big companies are becoming increasingly confident of sharing their data across cloud and the cloud providers have evolved a lot from their initial offerings. 

2. Siebel and subsequently Oracle needs to up their game to come up with a good cloud solution, else they will end up playing the catch up game for a lot of years to come. They are still playing the catch up to Salesforce.com, who is the industry leader. 

3. The industry leader Salesforce.com has a new competitor. SugarCRM who won the contract  has got the mother of all deals. SugarCRM is open source and is lot cheaper than Salesforce.com. IBM justified their decision of going with SugarCRM by saying that it is an open source system and it will interface well with the other IBM systems. 

4. Salesforce.com who is still the industry leader, is under pressure to keep the high margins. However, its the most expensive option compared to SugarCRM and Microsoft dynamics. They will probably have to take a look at their pricing model after this win, if they want to make sure that SugarCRM competition is kept in check. 

5. On the other hand, for SugarCRM, this can be considered a big big win and they might decide to become public and leverage this deal. The holding pattern of SugarCRM is not clear, but it is probably held by venture capitalists. 

Conclusion
This is a good news for the industry. There are rumors which suggest that Salesforce.com did not bid for this deal and their are rumors that Salesforce.com  was not invited. Either way this is not good for Salesforce.com. Having said that, Salesforce.com has a very strong and good suite of PaaS and SaaS. They are still the industry leader and will continue to do so for at least next 3-4 years. 

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.