1. One to One
2. One to Many/Many to One
3. Many to Many

One of the ways to get yourself equipped with the knowledge is to read through the Salesforce Fundamentals documentation. Well, that’s how I got to it while undertaking the Salesforce Certification – Developer. However, if you find that going through the materials a hassle, you can always refer to the following explanation on a quick run-down on how to build the data model.

One to One object relationship

Scenario:
One School can only have one Headmaster

Implementation:
This object relationship requires that one of the associated object to be unique.
- School (Master object)
- Headmaster (Detail/Child object)
- Create a unique field in Headmaster object
- Create workflow to copy the School id to the unique field for every record creation

One to Many/Many to One object relationship

Scenario:
One school can have many teachers

Implementation:
- School object
- Teacher object: School field (Lookup to School)

When you view the relationship from School, it’s ONE School to MANY Teachers
When you view the relationship from Teacher, it’s MANY Teachers to ONE School

Many to Many object relationship

Scenario:
Student can enrol in many subjects

Implementation:
- This is where junction object comes into play for this relationship
- Student Subject (junction object)
- Subject (Master object to Student Subject)
- Student (Master object to Student Subject)

This model explains that there are many students taking up many subjects and vice versa.

Hope this clears off any confusion you have with regards to the object relationships.

Furthermore, if you plan to perform a Salesforce migration with other applications and require to figure out the object relationship via API, you can simply generate the Salesforce WSDL of your current instance via:

Setup > App Setup > Develop > API > Generate WSDL

From there, you should be able to determine the definition of the object relationship. The following extensions explain on the references:

__c – in reference to the custom field id values

__r – in reference to the custom object relationship with the current object view

Here’s our brief analysis of the tool as compared to the Salesforce Data Loader:

Summary

For basic file uploads that do not require a database lookup this is a good tool.The pros for this tool are the scheduler and the monitor.   A good option for basic information uploads to Salesforce for sure.

The following example will demonstrate this issue:

trigger cloneAnotherAcc on Account (before insert) {
Account acc = new Account(name=’Clone me’);
insert acc;
}

This trigger will end up in an infinite loop.

In order for you to solve this issue, you can set a condition on insert so it will not be called recursively. Set a flag to manage the insert trigger will be the ideal. To do this, you need to create a new class to keep track the number of times of insert or stop the insert process on second time.

global class triggerCount {
static integer runTimes = 0;

public static integer getRunTimes(){
return runTimes;
}

public static void setRunTimes(){
runTimes++;
}
}

Once you successfully create this class, you can implement this triggerCount class on your trigger to limit the number of times for insert.

trigger createAcc on Account (before insert) {

if(triggerCount.getRunTimes < 2){
Account acc= new Account(name=’Clone me’);
triggerCount.setRunTimes();
insert acc;
}
}

Status Message: cli.Microsoft.Dynamics.GP.eConnect.eConnectException: Sql procedure error codes returned: Error Number = 6328 Stored Procedure taUpdateCreateCustomerRcd Error Description = The Customer Priority parameter is invalid: 1 to 100 are valid values.

Details on the integration:

• Dynamics GP 2010, SQL Server 2008, eConnect 11/2010
• The integration wasn’t using or passing the Customer Priority parameter
• This Customer record had been previously updated successfully by the integration
• This specific Customer caused the error, different Customer records could be updated without error

Analysis of the Customer record in GP showed that the Priority field was blank, Cards > Sales > Customer > Priority:

Anyone familiar with Dynamics GP, will know that the Customer Priority field is a dropdown and that blank is not a valid value for this field:

The solution was to edit the Customer in Dynamics GP and select a specific value from the dropdown box and save the customer record.  Everything worked fine after this so we concluded that a blank or invalid field was previously in the database for this Customer, causing the integration to fail.

You can configure a cache on any profile (say a Flat File of all your accounts). You can read in that file in one branch and map it to the cache, and set a key, say account ID.

If for example, you have a process that reads an order from a database or an app such as salesforce.com, you can, in the map step where you are mapping that, add the Cached Data, choose which field in the Order profile to link to the Key in the Cache (Account ID) and it will bring in that profile into the source map.  You can then map directly from any of the Order, or matched Account profiles to your target.

Nice.