The reason we're emphasizing this concept is that contacts are at the center of EDA. It also affects the way that EDA manages address data for contacts and accounts, because household accounts enable more complex address management. As you can see, the choice of administrative versus household affects the naming of accounts. If you're using the household account model, it would be named the Peterson Household Account. On the contact record, it looks like this: (EDA allows you to customize the naming convention of the container account-more on that in a later module.)įor example, contact Pete Peterson belongs to the Peterson Administrative Account. By default, the name of the new account uses the last name of the new contact. Whichever account model you go with, Salesforce creates the container account (administrative or household) for you each time you create an independent contact-that is, a contact that is not part of another account. Unlike the administrative account's one-to-one relationship, a household account typically contains multiple contacts besides the student, such as parents or guardians, siblings, and other members of a shared household. The household account functions just like its name suggests, to represent the household a student contact belongs to. You can think of an administrative account as the account-level representation of a contact. So for each contact that you create in EDA, you also have a unique administrative account. The relationship between the account and contact is one-to-one. The administrative account has a single contact associated with it-this is often a student but sometimes a faculty member, alumni, or other person related to the educational institution. EDA offers two kinds of container accounts: the administrative account and the household account. In the EDA account model, the standard Salesforce account object acts as a container account. But with EDA, has created an application that provides custom functionality geared toward how education audiences work. You can still do business tracking in EDA if you want to-standard Salesforce objects like opportunities and cases don’t go away. It gives you all the power of Salesforce without forcing you to customize the standard model to suit your needs. The EDA account model is closely aligned to the standard Salesforce account model. How then is one supposed to manage all these components in an application designed for business? With EDA and the EDA account model, has designed a great solution! The EDA Account Models We also want to keep track of things such as departments, sports teams, and alumni networks. But in addition to all that, we care about our students-what they’re doing, the classes they’re taking, and the clubs they belong to. Yes, we manage activities with companies and businesses that we partner with to attract potential students, high schools we recruit from, and other institutions that we receive transfers from. In the K-20 world, we track things a bit differently. How all these things relate to and interact with each other in Salesforce is known as an account model. ![]() Each account has people associated with it (contacts) and other things such as opportunities, cases, and tasks. ![]() ![]() In the traditional B2B scenario, each company keeps track of their accounts-the other companies or businesses that they are selling to. ![]() Understand the default account record types included in EDA.Ī quick Salesforce history lesson: Salesforce was originally designed as a business-to-business (B2B) application to help companies improve their sales processes, and by extension, maximize their sales.Explain the difference between the administrative account model and the household account model.Describe the difference between the Salesforce account model and the EDA account model.After completing this unit, you’ll be able to:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |