> ## Documentation Index
> Fetch the complete documentation index at: https://docs.superoffice.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Contact (person)

> SuperOffice view of the world and working with persons. The associate database table represents employees, resources, and other users - except for external persons.

![Edit person dialog -screenshot][img1]

## SuperOffice view of the world

SuperOffice has five important things:

* **Companies** are in code and database references called *contact*.
* **Associates** are SuperOffice users - employees of the company.
* **Projects** are a type of activity that usually involves several stakeholders and various types of other activities.
* **Activities** are things employees do with companies, contacts, projects, the diary, and sales.
  * Follow-ups
  * Documents
  * Mailings and form submissions
  * Chat sessions
* **Tickets** from Service are linked to persons who may or may not belong to a company.

You can [read more about the main tables][11] in the developer documentation.

### Business rules

* Activities happen at a particular point in time.
* Sales are expected to be closed on a date in the future.
* Meetings are scheduled for a particular date and time.
* Documents are written on a specific day.
* Activities start on one day and finish on another.
* Time is important for activities.
* Companies and projects are not time-specific but are linked to activities in time.

The appointment table contains foreign keys to all the other important tables, plus a date field (ActiveDate).

### Context-sensitive labels

It is important to keep in mind that there's not a 1:1 mapping of labels and that you have to take context into account.

| Real-world term           | UI label               | Database table | CRMScript class |
| ------------------------- | ---------------------- | -------------- | --------------- |
| company<br />organization | company                | contact        | Company         |
| person                    | contact<br />associate |                |                 |
| customer                  | contact                | person         | Customer        |
| employee                  | associate              | associate      |                 |
| user account              | user                   | ejuser         | User            |
| database owner            | tenant                 | Company        |                 |

<h2 id="associate">
  Employees (internal)
</h2>

The **associate** database table represents employees, resources, and other users - except for external persons.

Yet, this table is important for understanding and navigating the relationship between a person and their user account as well as the relationship between employees at the organization running the CRM system and the external parties they interact with.

You may think of associates as the missing link that connects people.

### Associate types

| Value | Type           | Description                                                                      |
| :---: | -------------- | -------------------------------------------------------------------------------- |
|   0   | Employee       | Internal person                                                                  |
|   1   | Resource       | Not a person<br />Disregard `personId`                                           |
|   2   | Anonymous      | Not authenticated for SuperOffice                                                |
|   4   | ExternalPerson | External person<br />No calendar                                                 |
|   7   | Anonymous      | Unknown<br />no person (1) + not authenticated (2) + no calendar (4)             |
|   8   | NoSentry       | Has full access rights<br />The Sentry mechanism is bypassed                     |
|   13  | System         | System user<br />no person (1) + no calendar (4) + full access/bypass sentry (8) |

### Frequently used values

| Database field | Description                                                  |
| :------------- | :----------------------------------------------------------- |
| associate\_id  | ID (primary key)                                             |
| person\_id     | The person                                                   |
| name           | Initials, sign-in name, database user name                   |
| group\_idx     | Primary group membership                                     |
| ejuserId       | ID of the user account<br />0 if not connected to an account |

### Important timestamps

| Database field | Description                             |
| :------------- | :-------------------------------------- |
| lastlogin      | The last time the associate signed in   |
| lastlogout     | The last time the associate signed out  |
| registered     | When the associate was registered       |
| updated        | The last time the associate was updated |

### Resources

Resources are typically meeting rooms or equipment such as projectors.

| Database field  | Description                      |
| :-------------- | :------------------------------- |
| isLocation      | True if it represents a location |
| locationAddress | The address, if it's a location  |

[Database reference][12]

### Associate list and cache

In NetServer when you have a session, the session cache will contain a special cache entry named the **associate cache**. There all the associates listed in the SuperOffice database can be accessed through the cache, which is much faster than retrieving the associates from the database.

The **associate list** is an MDO list type that you can retrieve from the database. It holds all the associates from the SuperOffice database.

[How to get associate list from cache][19]

<h2 id="blob">
  Person picture and BLOBs
</h2>

Pictures are stored in the BLOB table. The BLOBs are linked to other records in the system using the [BinaryObjectLink table][14].

BLOBs are currently used for four things:

* Pictures on person records
* Pictures on project records
* Flags on country records
* Status monitor pictures

If you add a picture to a person, you must write the picture to the [BinaryObject table][13], and then write the corresponding `BinaryObjectLink` to link the BLOB with the person record.

Without the link record, the picture will not appear.

### BLOB samples

* [Get person image (REST)][21]
* [Update person image (REST)][22]
* [Display person image (ImageUtility)][23]
* [Display image from BLOB table (web services)][24]

[11]: /en/database/getting-started#the-main-tables

[12]: /en/database/tables/associate

[13]: /en/database/tables/binaryobject

[14]: /en/database/tables/binaryobjectlink

[19]: https://github.com/SuperOfficeDocs/superoffice-docs/blob/main/docs/en/api/caching/associate-cache.mdx

[21]: /en/api/web-services/howto/contact/get-person-image-rest

[22]: /en/api/web-services/howto/contact/update-person-image-rest

[23]: /en/api/web-services/howto/contact/display-person-image-ws

[24]: /en/api/web-services/howto/contact/display-image-from-blob-table-services

[img1]: /media/loc/en/contact/edit-person.png


## Related topics

- [Company - overview (contact table)](/en/company/index.md)
- [Documents - overview](/en/document/index.md)
- [Follow-ups - overview (appointment table)](/en/diary/index.md)
- [Projects - overview](/en/project/index.md)
- [Sales - overview](/en/sale/index.md)
- [Working with contacts in CRMScript](/en/automation/crmscript/howto/contact/index.md)
- [Working with contacts in web NetServer services and REST](/en/api/web-services/howto/contact/index.md)
- [Working with contacts at the data layer (entities)](/en/api/entities/howto/contact/index.md)
- [Addresses](/en/api/localization/address/index.md)
