Need clarification to understand the Standard Field in Salesforce App - salesforce

I was creating the Recruitment App with Salesforce by going through the study material. I have a question. In the custom object, I saw that I have created a Standard field named "Position Title" and after that I have to create all other fields as "Custom Field & RelationShips". My question is -> Is it the case that Position title is the primary key/unique identified in this object? If that is the case, why the data type is Text(80)? I can have two records with same Position Title "Sr. Manager", right? In that case, my primary key/unique constraint violates.
I have attached the screenshot below:
I am new to salesforce. So please help me in understanding the system? Thanks in advance

Salesforce always create by default a group of fields called 'Standard fields', such as Created date, Last modified Date or Owner. In that list you'll probably interested in two, Id what is the primary key/unique identifier and Name which is a Text(80) field that you can't modify (only define if it's going to be text or an autonumber).
So to answer your first question, Name is actually not unique nor you identifier, and unfortunately at the moment salesforce doesn't give an easy option to have this functionality, in order to achieve that you could write a trigger with that restriction or define the Name as an autonumber and add the position title as a custom field with the unique checkbox marked.
The only problem with that last implementation is that the Name field is a special one with some behavior associated with it and it might obscure some of this functionality. For example, it will be the field shown when adding a relation to that object or in case you add the field to a related list, it will include a link to the actual object, but it will show the autonumber instead of the position title what doesn't give much information about the related object.
Here's a link with other people asking for the same idea.

Related

Salesforce - Refer custom field from standard object in custom object

I have a custom object. I would like to refer the custom field from opportunity object in my custom object as a read only field. How to do that?
You'd need some relation between the 2 tables in database. For example if you add a lookup field in your custom object, call it Opportunity__c & populate it on few recods, then you can display Opportunity Name but also reference other Opportunity fields in reports or formula fields. You could make another field (type = formula and then pick what matches the field you're interested in, text, date, checkbox...). Make the formula similar to Opportunity__r.MyCustomFieldOnOpportunity__c and you're good to go.
If you can't define any sensible relation between Opp and your custom object you'd have to tell us what exactly you try to achieve. Perhaps there's config (or code) way to copy values across. But making a lookup field and then a formula that jumps through this lookup is the most natural way.

Grab value from unrelated object where two fields match

I have two objects - "Account" and "Appointment". I'm trying to pull the value of the field "Status" from the "Appointment" object where "Account.Initial_Date" matches "Appointment.Date_Time". I initially tried making a new field in the "Account" object to return a text field and see if maybe it would return the first value:
Appointment__c.Status__c
Which results in the error:
"Field Appointment__c does not exist. Check spelling."
I was told that it's too difficult to link from "Appointment" to "Account" because there can be multiple appointments per account, which is why I'm trying to link based on the date fields. My next attempt was using VLOOKUP, but I read that this only works between custom objects, and I think I'm working with standard objects here... what kind of solution should I be looking for?
Adding the tag apex here in case this can only be achieved via a script of some sort - if that's the case, I'll make attempt via that.
I was told that it's too difficult to link from "Appointment" to "Account" because there can be multiple appointments per account
This is incorrect. That relationship appears to be exactly the same as that between Contact and Account - one Contact, many Accounts. It's a very common relationship pattern in Salesforce.
If an Appointment is logically related to an Account, it should have a relationship field referencing the Account object to which it is related.
However, having a one-to-many relationship does not mean you can trivially represent specific data points from the many side to the one side. The native tool to do so is the Roll-Up Summary Field, but it does not apply to your use case.
There's really three ways to implement your objective, which is essentially implementing a variant of a roll-up summary. VLOOKUP(), which works only in Validation Rules, does not apply here.
Write two Apex triggers (one on Account and one on Appointment) to react to all changes that would influence what value should appear in the Account__c.Status__c field.
Write equivalent Process and Flow declarative automation, which cannot get 100% of the way there because Process Builder and Flow cannot react to delete events.
Use the free and open source Declarative Lookup Rollup Summaries application to define a roll-up summary. DLRS can populate a field from the child object (Appointment) to the parent (Account) based on a sorting by another field (Date_Time__c).

Difference between Standard Fields and Custom Fields in Salesforce

I am kind of new to Salesforce. Could you please let me know what is the difference between Standard Fields and Custom Fields in Salesforce? Can I consider combination of Standard Fields as the unique identifier for a record?
Custom fields are just that. Fields that have been added to the standard Salesforce schema to tailor the data for each object. The user who creates the field can specify the field type and any applicable limitations, such as the maximum number of characters in a text field. These fields might be added to an Org via a managed package or through direct customization.
Standard fields in contrast are those that are already present in the Salesforce schema when a new Organization is created. They are present in all Orgs where the same features are enabled. You can't customize these fields to the same degree. E.g. you could change the display label, but not the underlying API name or data type.
You can see the list of the standard fields in the Salesforce Field Reference Guide
From an API perspective, custom fields are usually identified by a __c suffix (there are a few exceptions, such as GeoLocation fields).
Can I consider combination of Standard Fields as the unique identifier for a record?
You would usually rely on the Id field to be unique. If you wanted to augment this with another unique value, you would create a custom field and mark it as an External ID.
A composite key isn't directly supported. Instead you need to create a Unique Text field and then use a workflow field update or before trigger to populate the unique field with the components of the composite key.
Incidentally, the salesforce.stackexchange.com site is a great place to ask Salesforce specific questions.

Salesforce: Prevent autopopulating standard Name field

I have custom object on which there is a standard field 'Name'. The field type - text (Text(80)). It does not autopopulate, and the values ​​it can be set only through the edit page. This field is not mandatory on the project and on the edit page, but when I create a new record of this object this field is autopopulated by Id of this record. Although it is expected that the field should be left blank.
Can I fix this strange behavior with help of some options or settings? Are there any solutions?
I don't think so, it is either auto number or text in which case it'll be required, can not be left blank, salesforce autopopulates the record with the id in case you do not provide one and there is no setting to change that behavior (that i know of on current releases)
I'll recommend changing your requirements and at least populate the name of the record with something, a naming convention for the record on it's current stage would be helpful,
That way you can list all of your "ANONYMOUS" records and assign them into a queue so a business person can go and put the right info just to cite an example, a custom unique identifier which can be recognized by your system or an external application, but never blank

Efficient way to store a dynamic questionnaire?

In reference to this question, I am facing almost the same scenario except that in my case, the questions are probably static (it's subject to change from time to time, and I still think it's not a good idea adding columns for each question, but even I decided to add, how should the answers be specified/retrieved from), but the answers are in different types, for examples the answer could be yes/no, list-items, free text, list-items OR free text (Other, Please specify), multiple-selectable-list items etc.
What would be an efficient way to implement this?
Shimmy, I have written a four-part article that addresses this issue - see Creating a Dynamic, Data-Drive User Interface. The article looks at how to let a user define what data to store about clients, so it's not an exact examination of your question, but it's pretty close. Namely, my article shows how to let an end user define the type of data to store, which is along the lines of what you want.
The following ER diagram gives the gist of the data model:
Here, DynamicAttributesForClients is the table that indicates what user-created attributes a user wants to track for his clients. In short, each attribute has a DataTypeId value, which indicates whether it's a Boolean attribute, a Text attribute, a Numeric attribute, and so on. In your case, this table would store the questions of the survey.
The DynamicValuesForClients table holds the values stored for a particular client for a particular attribute. In your case, this table would store the answers to the questions of the survey. The actual value is stored in the DynamicValue column, which is of type sql_variant, allowing any type of data - numeric, bit, string, etc. - to be stored there.
My article does not address how to handle multiple-choice questions, where a user may select one option from a preset list of options, but enhancing the data model to allow this is pretty straightforward. You would create a new table named DynamicListOptions with the following columns:
DynamicListOptionId - a primary key
DynamicAttributeId - specifies what attribute these questions are associated with
OptionText - the option text
So if you had an attribute that was a multiple-choice option you'd populate the drop-down list in the user interface with the options returned from the query:
SELECT OptionText
FROM DynamicListOptions
WHERE DynamicAttributeId = ...
Finally, you would store the selected DynamicListOptionId value in the DynamicValuesForClients.DynamicValue column to record the list option they selected (or use NULL if they did not choose an item).
Give the article a read through. There is a complete, working demo you can download, which includes the complete database and its model. Also, the four articles that make up the series explore the data model in depth and show how to build a web-based (ASP.NET) user interface for letting users define dynamic attributes, how to display them for data entry, and so forth.
Happy Programming!
This may not fit you exactly, but here's what i've got at my part-time job.
I have a questions table, an answers table, and a survey table. For each new survey i crate a survey build (because each survey is unique, but questions and answers are repeated a lot). I then have a respondent table that contains some information about the respondent (and it also links back to the survey table, forgot that in the diagram). I also have a response table that links the respondent and the survey build. This probably isn't the best way but it's the way that works for me, and it works pretty fast (we're at about 1mill+ in the response table and it handles like a dream).
With this model i get reusable questions, reusable answers (a lot of our questions use "Yes" and "No"), and a rather slim response table.

Resources