Open CertifiedOnDemand.com Section Resources
This is not an exhaustive list; additional resources are referenced within objectives below.
|Explain how to create a custom object.||Managing Objects|
[Must / 5m / CertifiedOnDemand.com]
|Explain the difference between an object and a tab.||Exercise: Custom Object & Tab|
[Should / ~10-20m / CertifiedOnDemand.com]
|An object stores the field definitions and records. An object tab is used to expose an object's records within the user interface.|
To view the remainder of this content, you must purchase the Salesforce.com Certified Administrator Study Guide. Please Login or purchase the study guide.
John, what is the difference between Roll-up summary field and formula field? Can use formula instead of Roll-up summary field?
A rollup summary is used to summarize fields on a related object (e.g. the total of all opportunities related to an account).
A formula calculates values within a single record (e.g. commission of opp = amount * .10). Formulas can cross-reference through object relationships (but in the reverse direction of a rollup summary). You could have a formula on the opportunity that looked at the no of employees on the account, for example.
Can you try to explain two concepts in more detail but in plain non-technical, English, please?
1. What is a junction object and,
2. When a master-detail or Look-up relationship is created, how do we know where to create the relationship, i.e. on which object?
Thank you very much.
A junction object is an object that connects two (or more) other objects. The purpose is to allow you to create linkages between those objects.
E.g. without “Campaign Member” there would be no way to add a lead to campaign (Campaign < <- Campaign Member ->> Lead)
Relationships are created on the detail side of the relationships (campaign member has a relationship field to campaign, and to lead)
Hi John, The link to – “Overview of Relationships” in not working.
Sorry please disregard – Trigger Happy
Just confused with the following statement from Salesforce Documentation:
“When you delete a child record on a roll-up Summary field, Salesforce doesn’t recalculate the value of the field.”
When I delete/Undelete related opportunity’s record(s) of an account, the roll-up Summary recalculates the data and shows updated figures.
Please disregard my question
John, I’m confused by this statement (**) from the Salesforce documentation: Can you clarify?
Sharing access to a junction object record is determined by a user’s sharing access to both associated master records and the Sharing Setting option on the relationship field. See Custom Object Security. For example, if the sharing setting on both parents is Read/Write, then the user must have Read/Write access to both parents in order to have Read/Write access to the junction object. **If, on the other hand, the sharing setting on both masters is Read-Only, a user with Read-Only rights on the master records would have Read/Write access to the junction object.
How can a user obtain Read/Write access to a junction object if the sharing setting on both masters is Read-Only, and the user has Read-Only rights on the master records?
On the field definition you can define if you need read access to the parent record or read/write to the parent in order to edit child records. If you have multiple parents, then you the need the criteria from both met in order to edit child records.
So in practical terms let me give an example:
Object 1: Classroom
Object 2: Course
Object 3: Course Enrollment (join to classroom)
Course Enrollment has m/d relationships to classroom and course.
The setting for each of these fields is set to Read Only. (Allows users with at least Read access to the Master record to create, edit, or delete related Detail records.). My instructor (non admin) can enroll students into the course, but cannot edit the course or the classroom itself.
On the master/detail relationship field itself:
Sharing Setting Select the minimum access level required on the Master record to create, edit, or delete related Detail records:
Read Only: Allows users with at least Read access to the Master record to create, edit, or delete related Detail records.
Read/Write: Allows users with at least Read/Write access to the Master record to create, edit, or delete related Detail records.
Several questions on the use of standard objects:
1. Standard objects are by default shared among various Apps – is this right?
2. Is it a good practice in general to keep these standard objects shared among the various Apps (i.e. different App users can all access these standard objects)? I suppose not, since in real-world scenarios different Apps probably require different data to be save into these standard objects?
3. Does it make more sense in general to associate the standard objects with just one App and create custom objects for each of the other Apps separately?
4. Are standard objects clone-able through UI?
Hope the questions make sense.
1 – yes
2 – in general you want to stick with the out of the box config and then modify as needed. most organizations dont really use the standard apps, as you can’t change the logo.
3 – generally you create apps to match the selection of tabs/functionality that a group of users will need (e.g sales). It is not uncommon to have an app that exposes things differently for different groups (e.g. the sales app includes the campaigns tab – this tab is hidden for sales users but exposed for marketing users)
4 – clone the configuration of the object: no. Clone records: yes
hope that helps 🙂
Yes, that helps me understand how objects are used in real cases. Thanks.
is it necessary to go throught details about external object and relationships from exam point of view. it’s bit difficult to visualise since it can’t be tried in developer org instance.
Not overly important for the admin exam
I’ve just passed the exam! I highly recommend this COD site! Thanks John!
If i create a custom field on the account object to capture account credit status and want to display that field on opportunity object..
which feature should i use?..workflow field update (or) cross-object formula field ? and why?
Formula if you want the information to be read only on the opportunity. If you wanted to update the account field based on a change to the opportunity field then it could not be a formula.
First i want to ask you that …is the S-controls come under ADM(201)..if yes then,
Can you give some good link to understand S- controls in sales force and there features.
i read this document.(https://help.salesforce.com/apex/HTViewHelpDoc?id=dev_about_scontrols.htm)
but not getting much clear idea..do u have any suggested video for that.
No they should not be addressed- they are code-based and also completely deprecated (you can’t create new ones)
Re Max Number of Roll-Up Summary fields per object:
It says above that 10 is the max number of roll-up summary fields per object. I cannot find this reference in Salesforce documentation. Is this old information?
I think with the Winter ’16 release, that number have increased to 25 from 10.
Thanks for the note – this will get updated when I update the site for Winter 16
Thanks for putting together the guide. Its extremely helpful.
I have a problem I am struggling with.
I am trying to create a MASTER DETAIL relationship between two STANDARD Objects however I dont see that as option when I try creating a new field on a standard object?? I see that as option when I try and create a field on a custom object.
can you possibly guide me as to why I am seeing this behaviour??
It is a fact that salesforce does allow standard objects to be Master in a master detail relationship?? Funny why I cant see it as an option.
Also is there a limit on the number of Master detail relationships a STANDARD object can have? I believe the limit is 2 for Custom objects.
Will appreciate your advice on the above.
A standard object can never be the detail object within a master-detail relationship; you cannot establish the relationship you are attempting to create. I believe you are correct that the max is 2 master-detail relationships on one object (which is typical of a junction object). Cheers,
Hope you can clarify about Standard Objects being on the detail side of a Master Detail relationship. I was reading this SF article that you reference and the Many to Many example they give has a custom object “Bugs” that relates to Cases. In order for a bug to be related to many cases, there would have to be a master detail relationship between Bugs (Master) and Cases (Details). To test this, I created a custom object and added a master detail field to Cases. That put a related list on the Case record (one case to many bugs). However, there is only on Lookup field on the Bugs record so it’s not possible to relate a Bug to many Cases. Are they referring to a separate Lookup relationship for that part?
You can use master-detail relationships to model many-to-many relationships between any two objects. A many-to-many relationship allows each record of one object to be linked to multiple records from another object and vice versa. For example, you create a custom object called “Bug” that relates to the standard case object such that a bug could be related to multiple cases and a case could also be related to multiple bugs.
Good Q – In a m2m, you would need to create a junction object (e.g. Case Bugs) – the junction object would have the m/d relationship to both case and bug in that example. You wouldn’t have a direct relationship (e.g. lookup or master-detail) to/from case to bug, it would all happen through the junction object. Campaign — Campaign Member — Lead is an example of this as well.
Thanks Rovita for your response.
However; I think parent records can be deleted in a master detail relationship which will automatically delete the corresponding child records.
Pease clarify on the below questions.
1. While creating a lookup relationship you have an option – Don’t allow deletion of the lookup record that’s part of a lookup relationship. If this option is enabled then it does not allow me to delete the parent record (I hope I did the test correctly).
It looks almost similar to the behaviour of a master detail relationship when you enable this option from the lookup except you cannot delete the parent record if the parent has any child record. If this scenario is true then there would be some other reason/logic for not allowing to create a rollup summary if objects are related using lookup relationship.
2. Does Standard object always associate with the many/detail side in a lookup relationship or is there any exception?
1. The limitation was a decision made by Salesforce – I suspect for performance reasons, but ultimately I don’t know :/ No rollups without a master-detail relationship for custom objects, however. There are AppExchange packages that can work around that.
2. True for master/detail – a standard object is going to be the master of any custom m/d relationship created. Same is not true for lookups. E.g. A campaign that references a venue object via lookup relationship would be an example where the venue is the many side of the relationship.
Roll-up Summary fields calculate values from a set of related records. In a Master Detail relationship, the child cannot exist without a parent which means you cannot delete the parent, whereas in a Lookup relationship, child can exist without a parent. If the rollup summary field is referenced in, say a report, and you delete that record (which a possible in a lookup relationship), you don’t want inaccurate information. I think that is the reason why Rollup summary fields can be created only in a Master Detail relationship.
That’s a good thought Rovita – but the relationship between account and opportunity is a lookup (and yet you can use a rollup summary field). Ultimately it was probably a design/engineering decision made by Salesforce.
But, John, as you mentioned earlier, relationship between Account/Opportunity is non-typical!
Thanks John for the answer. My question is : I would like to know the logic or reason why rollup summary cannot be created if custom objects are related using lookup relationship.
This is a Salesforce limitation, why that limitation exists I’m not sure.
Let me take a shot at this.
Roll-up Summary sums up values from the Detail object and renders it on the Master Object. This is feasible because, in a Master-Detail relationship objects are bound to each other (i.e. a child has to have a parent). In a Lookup relationship, on the other hand, the child does not have to have a parent. So, summing up values of a child object and rendering it on a parent object does not make sense in a Lookup relationship because, here, a parent and child do not have a binding relationship and are not committed to each other.
Why roll up summary field is getting disabled while selecting a look up relationship for a particular field? Is there any specific logic behind that?
Not sure exactly what the question is – a rollup summary can only be created with master/detail relationships or select lookup relationships (e.g. account/opportunity). There may be limits on the fields that you can filter on (e.g. you may not be able to filter data based on a cross-object formula)…
Is there a list of which features require activation? I also am fuzzy on what the correct terms are for ‘something the admin needs to turn on’ (“enabling??”) vs ‘something salesforce support needs to turn on’ (“feature activation”??).
Feature activation = contact support. Unless specifically mentioned, a feature should be configured (versus activated). I don’t know of any list although that would be great if there were one!
Administrator made one field as required field but there are few user still able to create record without completing the required field. How Administrator can sort this issue.
a. Make sure field level security is not set to “read only” in user profile.
b. Make sure field set as required on all page layouts assigned in profile.
c. make sure the user have “edit permission” on field in assigned profile.
d. Make sure user have “Modify All” permission in profile.
Please if some explain from his/her experience.
Probably make sure field is required on page layout. However, that would not stop the user from creating records via the API without the field populated.
None of the other answers would either though – what would really work is to modify the field itself and make the field required – this would be enforced via the API as well.
Though it’s an old question, let me elaborate what John has already said about making the field required in a page layout.
The answer should be choice b.
I think the choice is not worded correctly. It should be – Make sure field ‘is’ set as required on all page layouts assigned in profile..
There are 3 ways to make a field required
(reference: https://help.salesforce.com/apex/HTViewSolution?id=000003107&language=en_US )-
1. Field level Requirements:
This is the most restrictive of requirements and it requires the field to be entered all the time, regardless of how the record is saved (i.e. through an integration, the API, mass upload, or through the User Interface)
2. Page Layout
This option only makes the field required when the specific page layout that you make this field required is accessed. Therefore, you could technically make this required for some users using a particular page layout but not others.
3. Validation Rule Requirement
By creating a rule to check if the field isBlank or isNull (in case of number or currency field)
Great summarization thanks Rovita.
Question – if in a master detail relationship, the detail object can not be a standard object, how come Account-Opportunity is a master detail relation as both are std objects?
The relationship between opp and account is non-typical. If you were to recreate the relationship using custom objects, it would have to be a master-detail relationship. SFDC probably did this to facilitate rollup summaries specifically on the account/opportunity relationship (as it is quite a popular one) despite the lookup relationship between the two.
I’ve created a tab and marked it as hidden for an object. Can I still search for the records in that object?
If the tab is hidden you should not get search results
Is search not dependent on the profile access on record? means if profile has read or edit access; then can we search the record in object irrespective of the fact that tab is hidden?
If the tab is hidden you should not see the search results however you would be able to access the data (eg via API or a related record) if you have read access.
I am confused about the the limits with respect to Recycle Bin. Can you please confirm with respect to latest update/information?
Number of days the following will remain in the recycle bin until they are permanently deleted?
Deleted records – 15 days or 30?
Deleted objects – 15 days or 30?
Deleted custom fields – 15 days or 45?
Me & a couple of colleagues had this question too, any ideas?
Sree- it is 15 days all around. Do I reference other periods on the site?