# SE Services
Descriptions for blocks mentioned here https://miro.com/app/board/uXjVOHqwraI=/

## Client
Simple service that serves as a home for Clients (service companies). Responsible for producing Kafka CRUD events for each client. The most general details about a Client such as name, address, phone, etc. are stored. More specific details may reside in others services. For example, the Scheduling Service contains client records that have a blacklist definition that allows statuses/codes/technicians to be ignored when calculating availability. Other entities that reside in this service include Branches and ERPs.

## Trade
Simple service that serves as a home for Schedule Engine’s Trades as well as the definitions describing which clients offer which trades.

## Room
Simple service that serves as a home for entities that help with Schedule Engine’s UI. For example, details about the Rooms, Icons, and Issues (questions) customers see in the Widget reside here.

## Customer
Simple service that serves as a home for Customers (or homeowners). Customer details include property name, relationship to the property, etc.

## Location
Service that is responsible for storing site location data for the customers of our clients. A location is the combination of an address, the customers associated to the location and roles those customers have.

## Contract
Simple service that serves as a home for Contracts between a Client (service company) and a Customer (homeowner). Contracts are also known as preventative maintenance or service agreements.

## Technician
Simple service that serves as a home for a client’s Technicians. Responsible for producing Kafka CRUD events for each technician. The most general details about a technician such as name, avatar, phone, etc. are stored. More specific details may reside in others services. For example, the Scheduling Service contains details about where (branch/zone) a specific technician can work and what (trade/code) that technician can do.

## Vehicle
Serves as a home for a client’s Vehicles. Responsible for producing Kafka CRUD events for each vehicle (including location updates). Integrates with 3rd party vehicle tracking providers such as Fleetmatics. Vehicle details include attributes from make and model to tank capacity and miles per gallon. Some of the vehicle location details include longitude, latitude, speed, and heading.

## Lead
Service used to capture partial appointments. For example, a user that got half way through the widget, but didn't click "book now" will have a lead record.

## Appointment
Service that is responsible for storing appointment and visit records. Depending on the clients ERP, the appointment is the normalized representation of the job, work order, or dispatch. Visits will then represent each individual technician line item for the appointment.

## Scheduling
Service that is responsible for maintaining capacity and determining availability for a client. Serves as a home to Service Zones and Codes as well as Availability Timeslots and Throttles. Also consumes various Kafka events and replicates any data required to determine availability; for example Technicians and Visits.

## Media
Service that provides a way to upload/download files. Currently integrates with S3, but meant to be an abstraction that could work with other 3rd party providers too. Each uploaded file is given a unique id that can be referenced at a later time to download, update metadata, or change permissions. Some of the metadata stored about each file includes MIME type, size, and filename.

## Client Feature
TODO

## Preventative Maintenance
TODO

## Partner
Used for SE Enterprise. Partners are records that associate to Client records to denote a partnership. For example, Haller (a service company/client) might have 2 Partner records indicating their relationship to Rheem and Fujitsu (OEM companies/clients)

## Job
Simple service that runs a suite of jobs. Each job has its own schedule described with a CRON pattern. This service is guaranteed to only ever have one instance running to ensure exclusive execution. The work of intensive jobs can be distributed to other services via REST calls and/or Kafka events.

## Certification
TODO

## Whiteboard
TODO

## Appointment Notification
Service that is responsible for configuring, scheduling, sending appointment notifications, and handling customer responses for SE Notify.

## Theme
TODO

## Job Adapter
TODO

## Feedback
TODO

## Public
TODO

---

## Auth Services
- admin auth
- client auth
- agent auth
- device auth (partners too)

## Notification
Service that provides a way to send SMS/voice/email notifications and receive responses to those notifications. Currently integrates with Twilio, but meant to be an abstraction that could work with other 3rd party providers too. For each notification sent, a callback URL with arbitrary parameters can optionally be defined. If/when a recipient responds to the notification, a POST request is made to the callback URL with their reply and any parameters defined. This removes the Notification Service from the equation when action is required on a reply. In addition all outgoing/incoming notifications are logged in such a way that a conversation history can be built.