What happens when you delete a custom object that’s related to a standard object by a lookup field?
You would get an error that an existing relationship referenced that object- you’d have to remove the lookup field first
Please correct me if my understanding is wrong in this. As per the video the custom object created was set to ‘Default On’. However, the created custom object doesn’t appear in the tab and was seemed to be accessible by clicking on the ‘+’ sign, which i believe is default off. Please clarify – Thanks
It has to be ‘default on’ and also added to the application in order to appear along the list at the top of the screen
Could you please let me know which will be the answer for below question.
A user is setup with a profile that allows create, edit and delete access to Vehicle (Custom object). The OWD setting for Leads has been set to private. What will the user’s access be to other users record (Vehicle).
A. The profile setting will override the sharing setting and the user will be able to edit other user’s Vehicle.
B. The user will not be able to read, edit or delete other user’s leads
C. The profile setting will not override the sharing setting. The user will have access to other user’s Vehicle granted via the role hierarchy.
In my opinion the ans will be B because it may possible that granted via the role hierarchy option is unchecked for the custom object.
Doesn’t say if grant access using hiearchies is turned on – if it is (which is the default), then C. If it isn’t, then B
So if it is not mentioned in the question then we can say C is the answer right because by default it is on.
I just found this question on line:
Sales reps at AW Computing need assistance from product managers when selling certain products. Product managers do not have access to Opportunities but need to gain access when assisting on a specific deal. How can the system administrator accomplish this?
A. Notify the product manager using opportunity update reminders
B. Use similar opportunities to show opportunities related to the product manager
C. Enable account teams and allow users to add the product manager
D. Enable sales teams and allow users to add the product manager
I chose C and I get the message that is wrong and the correct answer is D.
We have Teams on Accounts, Opportunities and Cases, but I couldn’t find “Sales Team” on Google.
Are “Teams” part of the Adm Cert exam or only on the Advanced Exam?
That’s referring to opportunity teams
I understand that it is related to Opportunity, but I don’t understand “Enable sales team” when I don’t find any reference to “sales team”. If I go to Setup and type “Teams”, I find it for Accounts, Opportunities and Cases.
Is the “sales” reference a tricky one?
Also, are “Teams” part of the 201 exam or the 211?
Its called opportunity teams in setup (used interchangibly with sales team)- and yes I would expect it to be included in the ADM201 exam.
Maybe mention if the names are case sensitive? For example will JOB_POSTING__C work in the API?
It should – apex is insensitive, and you can’t have two fields with the same api name but different case
How object oriented is the SF data model? In other words, can you extend standard objects and thereby inherit their fields (and behaviors).
I want something similar Accounts + Contacts, but not exactly – slightly different data/different behavior. I am trying to envision an optimal data model for nonprofit sports management scenario where you have Teams and Players. Players can exist (temporarily) without a team instance, but can “belong” to different teams over time. This tells me Master-Detail wouldn’t work
So rather than invent two new objects, and duplicate a bunch of fields, just extend the OOTB objects and tweak where needed.
Hope the question is clear. This probably out of scope for your website (and perhaps even for SFDC) but looking for some best practices in this regard.
There are two options: master detail and lookup to create relationships. Master detail has property inheritance, lookup does not. You are correct in thinking that a m/d relationship for this use case would not work, as you could not have a teamless player (unless you created an arbitrary team called “no team”).
For your relationships, I would create a junction object between team and player.
The junction object would be a master/detail relationship to both parent objects (team and player).
So under your player record, you would add a “team membership” or something like that. Then you could add fields to this object to indicate if this was past, present, active, etc. Hope that makes sense.
John, are there times when it’s just better to create a new record type/page layout within a standard object as opposed to creating a brand new custom object? Thx.
Yes – really depends though
I saw an example where a company created a custom object for opportunities of another department- almost always advisable to use record types in those kind of situations.
My objection creation wizard has only one step. It is not giving me the option to set tab default on or off. Ideas?
There is an object wizard and then a tab wizard. The object wizard prompts you if you want to create a tab- the tab wizard has the on/off selection, not the object creation.
The table in the video states that “__c” is appended to the object name. But that doesn’t seem to be the case, either in the example you show in the video or in what I’m doing now in the exercise in my dev instance.
maybe it’s just clarity that is needed. When I went to look at the custom object again, the API Name has the appended bit. But the Object Name does not.
The object label is what the user sees- the api name should have __c appended for custom objects.
Exactly. In the video, the custom object’s API name does not have the __c appended to it.
I see it in the final page when the object is saved, but SF clearly states that when entering the object name, this is the API name that will be referenced and there is no __c until it is saved and the object name in fact does not have the __c, just the API.
Your comment is correct broncosi – the API name (“Field Name” in setup) will always have __c appended once the object is created (the same is true for fields). This is only true for custom fields/objects (__c stands for “custom”).
The field label (what the user sees) will not have __c appended.
Hi – your final comment is kind of a cliff hanger – i.e. it is clear that deleting the custom object removes the aspects stated in the warning pop-up, however it is unclear precisely which aspects will be unrecoverable without rebuilding if subsequently restoring within the 15 day limit?
That level of detail is best explored in the documentation – I would certainly recommend exploring that topic. Good point!
You must be logged in to post a comment.