Skip to main content

Contacts

The Contacts area in CRM & operations is the center of Scoutello contact management. It lists the people, companies, suppliers, members, partners, guests, leads, and other entities an organization tracks for sales, hospitality, events, memberships, support, or operational follow-up. The underlying records and routes are also called customers.

Route: /organizations/:id/customers

Customer detail route: /organizations/:id/customers/:customerId

What A Customer Record Represents​

A customer record can be a classic contact, but it can also represent more operational concepts:

  • A person who attends an event, receives a newsletter, or logs into a private web app.
  • A company or account with related people and projects.
  • A supplier, partner, guide, sponsor, speaker, venue, association member, repeat guest, or internal stakeholder.
  • A record created manually, imported from a file, copied from another permitted organization, scraped/enriched, or generated by a guest-facing form or event flow.

The customer is the best starting point for support because many CRM and guest-facing flows eventually attach to it.

Important Fields​

Customer records can include:

  • Identity: first name, last name, title, department, job title, company name, type, linked user account.
  • Contact details: email, phone, second phone, website, LinkedIn, Facebook, Instagram, YouTube, XING, Bluesky, and other social links.
  • Classification: type, status, source, tags, custom fields, notes, descriptions, and order.
  • Personal profile fields: age, date of birth, gender, pronouns, spoken languages, images, and profile visibility settings.
  • Organization context: owning organization, associated organization, responsible customer, role, permissions, invited/accepted state, and member access.
  • Network context: customer relations, referrals, responsible-for links, project participation, assigned projects, assigned events, assigned tours, assigned landing pages, assigned offers, and assigned newsletters.
  • Communication context: inbound emails, sent mails as sender, personal sender local part, contact email, email signature, newsletter subscriptions, and email opt-out state.
  • Operational context: tasks, protocols, documents, event participants, invoices, contact form submissions, saved entries, short links, and landing page access.

Not every field is visible in every form. Visibility depends on customer type, permissions, organization setup, and the current tab.

Types And Statuses​

Customer types used by the dashboard:

  • Person: individual contact, guest, member, attendee, team member, or stakeholder.
  • Company: company or customer account.
  • Supplier: vendor or supplier contact.
  • Other: fallback for records that do not fit the standard categories.

Customer statuses used in CRM lists:

  • prospect
  • first_contact
  • proposal_sent
  • in_negotiation
  • low_confidence
  • won
  • lost

Support should treat these statuses as operational labels. They help teams filter and understand pipeline or relationship state, but they do not by themselves grant access, send emails, or change event participation.

List Views And Filters​

The customer list supports table behavior, mobile list behavior, and kanban-style views. Common list controls include:

  • Search and column filtering, including person and company context.
  • Status and type display.
  • Last-updated date range filtering.
  • Show externally added records.
  • Show records with permissions.
  • Show only assigned records.
  • Bulk selection and bulk edit where permitted.

If a user says a customer is missing, check the active organization, permissions, assigned-only scope, search text, quick filters, date filter, and whether the record exists in another organization.

Creating And Importing Customers​

Users with the right permissions can create customers manually or import them.

Common entry points:

  • Create: create a new customer record.
  • Import from file: upload customer data from a file import flow.
  • Import from organization: copy permitted records from another organization.
  • Scrape/import leads: use a scraping flow where enabled.

When creating or updating person-type customers, Scoutello can link an existing user account by email in supported flows. Duplicate email checks are organization-aware, so support should verify the organization before assuming a duplicate belongs to the same CRM dataset.

Import a spreadsheet​

  1. Open the file-import action in Contacts. Choose the example/template method or assisted column mapping.
  2. Upload an XLSX, XLS or CSV file. Select the sheet and the header/data rows to use.
  3. Review the column mapping. Map useful columns and explicitly ignore columns that should not be imported.
  4. Inspect the editable rows, then request the server review.
  5. Review validation issues, duplicate-email matches, company relationships and proposed creates/updates. Correct blocked rows before confirming.
  6. Confirm the reviewed import and inspect the per-row results. For an interrupted import, use its retry action to continue the existing reviewed import.

Reviewing or mapping a file does not write its contacts. Importing does not send invitations or newsletter emails. A duplicate match and an access-bearing/member contact have different protections; inspect the review instead of assuming every match will be overwritten.

If the review expires before import begins, review the current rows again. After an interrupted import, follow the displayed session/recovery state and preserve successful row results.

Delete and restore​

Deleting a contact removes it from the active list and places eligible records in Trash. Open Trash to inspect the deletion time, deleting person and permanent-cleanup deadline. Restore a record before its displayed deadline; after that deadline it may be awaiting cleanup and no longer restorable.

Permanent deletion has a separate confirmation and permission check. It queues cleanup and cannot be treated as an undoable archive. A cleanup-pending or failed status should be investigated rather than interpreted as a restored contact.

Some records are protected because they carry organization membership or access. Confirm the record type and linked access before promising deletion or restoration.

Giving A Person Dashboard Access​

Dashboard access starts from a person in Contacts. The dashboard workflow is:

  1. Open Contacts and select Create contact.
  2. Choose Person, enter an email address, and save the contact.
  3. Open the Access tab on the saved contact.
  4. Choose the appropriate role and save the access settings.
  5. Select Send invitation.

Creating the contact or saving the role does not send the invitation automatically. Only the final Send invitation action does that. Explain this as one contact-and-access workflow; dashboard users do not need a separate platform account or an internal administration area.

Customer Detail Tabs​

Existing customer records can show multiple tabs:

  • Overview: high-level contact context and quick actions.
  • Advanced: detailed customer form fields and newsletter subscription controls.
  • Relations: direct relationships to other customers.
  • Referrals: who referred this customer and who this customer referred.
  • Protocols: interaction history for the customer.
  • Documents: files linked to the customer.
  • Tasks: follow-up work linked to the customer.
  • Emails: inbound or outbound email context for the customer.
  • Events: event participation and event links for person records.
  • Access: profile, role, permissions, and web app access settings for person records where editable.

Tabs appear only when the user has the relevant role permissions, the organization has the required module access, and the customer type supports the tab. Basic contact management remains available in the free foundation; advanced CRM relationships, history and integrations require CRM for modular organizations.

Quick Actions​

From customer lists and detail pages, users may be able to:

  • Create a protocol.
  • Create a task.
  • Compose an email.
  • Add the customer to a newsletter.
  • Add the customer to an event.
  • Add the customer to a project.
  • Add a relation.
  • Clear externally added flags.
  • Bulk edit or delete selected customers.

The available actions depend on the active user's role, blocked state, customer type, organization membership, and entity permissions.

How Customers Connect To Other Modules​

  • Protocols explain what happened with the customer.
  • Tasks show what still needs to happen.
  • Documents store files relevant to the customer.
  • Projects show longer-running initiatives involving the customer.
  • Newsletters show subscription and campaign-list context.
  • Email shows conversations and sender/recipient context.
  • Events show invitations, participation, tickets, check-in state, and assigned-customer context.
  • Landing pages and tours can use customer access and assignment records for private or targeted experiences.

Permission Notes​

The customer sidebar item appears when the user can list or read customers. Create, edit, delete, and assigned-only behavior is controlled separately by organization permissions.

Important support implications:

  • Assigned-only users may see only records connected to their responsible or assigned context.
  • A user may be able to read customers but not create, edit, delete, bulk edit, or import them.
  • Access/profile fields are sensitive because they can affect member roles, private web app access, and what information appears in public or member profiles.
  • Additional controls can appear when the current organization role allows them.

Common Support Scenarios​

A customer is missing from the list​

Check:

  1. Active organization in the URL.
  2. Search, quick filters, date filters, and assigned-only filter.
  3. Customer permission scope for the user.
  4. Whether the customer belongs to another organization.
  5. Whether the record is externally added or hidden by a filter.
  6. Whether the user is viewing a project, event, newsletter, or customer-specific subset rather than the full organization customer list.

A duplicate customer cannot be created​

Check whether another customer in the same organization already uses the email address. Person-type records can link to users by email, so email uniqueness and user linkage are often involved.

A tab or action is missing​

Check the entity permission for the tab or action. For example, missing protocols usually points to protocol list/read permissions; missing task actions may point to task create/edit permissions; missing documents points to document list/read/edit permissions.

A customer does not appear in a newsletter, event, or project​

Check whether the customer has been explicitly assigned or subscribed, whether the customer type is supported by that flow, and whether assigned-only filtering is active.

Related concepts: Protocols, Documents.