Answers.Body: <p>The employee/employer connection is a relationship - you can add it from the relationship tab, and include start and end dates to build up an employment history. I assume it's also in the initial contact record entry form because a lot of people do want to record the current employer.</p>
  
  <p>If you're really sure you don't need a separate contact, and don't need information about how individuals are employed, then there isn't much point in recording it. If you're picking up the data and don't want to lose it, maybe just add it as a note? That way the information is there, but you don't have superfluous contact records (and you don't have to worry about whether they're still employed by the same organisation a year later).</p>
  
  <p>We have a similar situation - sometimes the organisation is needed, because that's the source of our contact with the individual, but sometimes we only know their employer because they've signed up to our newsletter with their work email - it doesn't have any impact on our connection with them. It's tempting to fill up every field just because it's there, but if it's never going to be used, it's just more data that needs to be checked and updated.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-24T14:03:03.893Z
Answers.LastActivityDate: 2015-11-24T14:03:03.893Z
Answers.UserDisplayName: liblogger
Answers.Body: <p>One of the distinct advantages of CiviCRM is that nobody is limiting your number of contacts.  Although there is admittedly a bit of overhead in maintaining organizations--mainly in merging different wordings and abbreviations of the same place--this is less trouble than you'd go through to prevent these contacts from being created.</p>
  
  <p>Like the proverbial tree falling in the forest, a contact in your database doesn't make a sound if nobody's searching for it.  Mark your important contacts in ways that you'll find them, but a contact that's just in there as an employer won't clutter up your work unless you're making grossly over-broad queries.</p>
  
  <p>(Besides, who knows if they'll end up as the employer of other contacts?  You might consider a workplace giving program.)</p>
  
  <p>Most importantly, don't let the mere existence of a contact in your database signify anything to you.  Segment your data based upon location, activity, opt-ins to lists, and so forth.  If a contact is exclusively an employer of another contact, with no further information, they'll never have any of this other data--the information that you should really be basing your communications and analysis on.</p>
  
  <p>In short, don't fight this core feature of CiviCRM.  It's innocuous, and it would be confusing and/or expensive to work around.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-12-06T04:42:15.117Z
Answers.Text: Thanks for that perspective. I still think there's a level of wanting to guide people in entering data because the mere data entry and data management stuff is time-consuming, seems weird to take time to enter employment data when quite irrelevant. I also worry about it becoming outdated and then people feel inclined to update this stuff. It's more to manage…
Answers.UserDisplayName: wolftune
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-12-07T05:24:23.940Z
Answers.Text: There's no need to have people enter their employers' names--it's perfectly fine to leave the field blank and never include it in a profile.  My opinion is just that you shouldn't go out and fight against CiviCRM and how it handles employers.
Answers.UserDisplayName: Andie Hunt
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-12-05T03:27:53.977Z
Answers.LastActivityDate: 2015-12-05T03:27:53.977Z
Answers.UserDisplayName: Andie Hunt
Body: <p>So, sometimes a contact's employer is entirely irrelevant, we have basically no value in keeping that information. Or maybe there's no reason not to note it, but it's not an organization we care about.</p>
  
  <p>How should we manage this type of situation? I don't really want to clutter our contact lists with all sorts of random companies just because they employ someone. Is my thinking sensible in terms of avoiding making extra contacts?</p>
  
  <p>Can/should I make an employer field that is custom that doesn't require the entry to have its own contact record? Should we just accept the excessive contact records? Or should we leave employer blank whenever we don't think we want a contact record for that institution?</p>
  
  <p>Basically, the employer part seems confusing. It seems it would have made more sense to just make it a simple field like any other and choose to enter employers and add the relationship in just those cases where it seemed worthwhile, and it would then make it far easier to deal with cases where we want more info, such as for people who have multiple employers and/or track their employment changes over time…</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-11-24T19:32:53.460Z
Comments.Text: " it would have made more sense to just make it a relationship like any other " - did you mean "make it a field like any other'?
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-11-26T05:38:40.313Z
Comments.Text: Yes, in that sentence, I meant "field", editing
Comments.UserDisplayName: wolftune
Tags: <contacts><custom-fields><relationships><contact-types><data-model>
Title: How to handle irrelevant employers we don't really want as separate contacts?
ThreadText: # How to handle irrelevant employers we don't really want as separate contacts?
  
  (Asked by: username_0 on 2015-11-24)
  
  So, sometimes a contact's employer is entirely irrelevant, we have basically no value in keeping that information. Or maybe there's no reason not to note it, but it's not an organization we care about.
  
  How should we manage this type of situation? I don't really want to clutter our contact lists with all sorts of random companies just because they employ someone. Is my thinking sensible in terms of avoiding making extra contacts?
  
  Can/should I make an employer field that is custom that doesn't require the entry to have its own contact record? Should we just accept the excessive contact records? Or should we leave employer blank whenever we don't think we want a contact record for that institution?
  
  Basically, the employer part seems confusing. It seems it would have made more sense to just make it a simple field like any other and choose to enter employers and add the relationship in just those cases where it seemed worthwhile, and it would then make it far easier to deal with cases where we want more info, such as for people who have multiple employers and/or track their employment changes over time…
  
  **Tags:** contacts, custom-fields, relationships, contact-types, data-model
  
  > **Comments:**
  > **username_1**: " it would have made more sense to just make it a relationship like any other " - did you mean "make it a field like any other'?  
  > **username_0**: Yes, in that sentence, I meant "field", editing  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2015-11-24. Score: 0 | Accepted answer
  
  The employee/employer connection is a relationship - you can add it from the relationship tab, and include start and end dates to build up an employment history. I assume it's also in the initial contact record entry form because a lot of people do want to record the current employer.
  
  If you're really sure you don't need a separate contact, and don't need information about how individuals are employed, then there isn't much point in recording it. If you're picking up the data and don't want to lose it, maybe just add it as a note? That way the information is there, but you don't have superfluous contact records (and you don't have to worry about whether they're still employed by the same organisation a year later).
  
  We have a similar situation - sometimes the organisation is needed, because that's the source of our contact with the individual, but sometimes we only know their employer because they've signed up to our newsletter with their work email - it doesn't have any impact on our connection with them. It's tempting to fill up every field just because it's there, but if it's never going to be used, it's just more data that needs to be checked and updated.
  
  
  ---
  
  ### Answer by username_3 on 2015-12-05. Score: 2
  
  One of the distinct advantages of CiviCRM is that nobody is limiting your number of contacts. Although there is admittedly a bit of overhead in maintaining organizations--mainly in merging different wordings and abbreviations of the same place--this is less trouble than you'd go through to prevent these contacts from being created.
  
  Like the proverbial tree falling in the forest, a contact in your database doesn't make a sound if nobody's searching for it. Mark your important contacts in ways that you'll find them, but a contact that's just in there as an employer won't clutter up your work unless you're making grossly over-broad queries.
  
  (Besides, who knows if they'll end up as the employer of other contacts? You might consider a workplace giving program.)
  
  Most importantly, don't let the mere existence of a contact in your database signify anything to you. Segment your data based upon location, activity, opt-ins to lists, and so forth. If a contact is exclusively an employer of another contact, with no further information, they'll never have any of this other data--the information that you should really be basing your communications and analysis on.
  
  In short, don't fight this core feature of CiviCRM. It's innocuous, and it would be confusing and/or expensive to work around.
  
  > **Comments:**
  > **username_0**: Thanks for that perspective. I still think there's a level of wanting to guide people in entering data because the mere data entry and data management stuff is time-consuming, seems weird to take time to enter employment data when quite irrelevant. I also worry about it becoming outdated and then people feel inclined to update this stuff. It's more to manage…  
  > **username_3**: There's no need to have people enter their employers' names--it's perfectly fine to leave the field blank and never include it in a profile.  My opinion is just that you shouldn't go out and fight against CiviCRM and how it handles employers.  
  
  ---
  
  