> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nekt.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Sults as a data source
> Bring data from Sults franchise management to Nekt.
Sults is a Brazilian franchise management platform used by franchisors to run their networks: unit
registries, support tickets, field audits (checklists), implementation and expansion projects,
internal announcements, and centralized purchasing. This connector extracts all of it — units and
their people, tickets with full interaction timelines, checklist evaluations down to each answer and
action plan, project and implementation tasks, announcements with per-user read receipts, and the
purchasing catalogue with orders, prices, stock, and product assortments.
## 1. Add your Sults access
1. In the [Sources](https://app.nekt.ai/sources) tab, click on the "Add source" button located on the top right of your screen. Then, select the Sults option from the list of connectors.
2. Click **Next** and you'll be prompted to add your access.
* **API Token (v1)**: required. Generate it in Sults under **Segurança > API**. It serves the units, people, tickets, checklists, projects, implementation, and expansion streams.
* **API Token (v2)**: optional, but required for the announcements and purchasing streams. Generate it at `https://YOUR-COMPANY.sults.com.br/seguranca/api/sults-token/2`, replacing `YOUR-COMPANY` with your Sults subdomain.
* **Initial sync date** (advanced): earliest date to sync. It applies only to the two streams Sults can filter by date — tickets (last change) and checklist evaluations (end date). Leave empty to sync all history.
Sults issues two incompatible tokens. A v1 token is rejected by v2 endpoints and vice versa, so both
fields must be filled to sync every stream. If you leave the v2 token empty, the announcements and
purchasing streams are skipped and their tables are simply not updated.
3. Click **Next**.
## 2. Select your Sults streams
1. The next step is letting us know which streams you want to bring. You can select entire groups of streams or only a subset of them.
> Tip: The stream can be found more easily by typing its name.
Sults sells each module separately. If your contract does not include a module — purchasing, or the
product assortment feature, for example — its endpoints answer with a permission error, and the
connector skips those streams with a warning in the run log instead of failing the run.
2. Click **Next**.
## 3. Configure your Sults data streams
1. Customize how you want your data to appear in your catalog. Select a name for each table (which will contain the fetched data) and the type of sync.
* **Layer**: companies in the Growth plan can choose in which [layer](https://docs.nekt.com/get-started/core-concepts/catalog-layers) the tables with the extracted data will be placed.
* **Table name**: we suggest a name, but feel free to customize it. You have the option to add a **prefix** to all tables at once and make this process faster!
* **Sync Type**: depending on the data you are bringing to the lake, you can choose between INCREMENTAL and FULL\_TABLE. Read more about Sync Types [here](https://docs.nekt.com/get-started/core-concepts/types-of-sync).
2. Click **Next**.
## 4. Configure your Sults data source
1. Describe your data source for easy identification within your organization. You can inform things like what data it brings, to which team it belongs, etc.
2. To define your [Trigger](https://docs.nekt.com/runs/scheduling-and-triggers), consider how often you want data to be extracted from this source. This decision usually depends on how frequently you need the new table data updated (every day, once a week, or only at specific times).
3. Optionally, you can define some additional settings (if available).
* Configure Delta Log Retention and determine for how long we should store old states of this table as it gets updated. Read more about this resource [here](https://docs.nekt.com/get-started/core-concepts/resource-control).
* Determine when to execute an **Additional [Full Sync](https://docs.nekt.com/get-started/core-concepts/types-of-sync#additional-full-sync)**. This will complement the incremental data extractions, ensuring that your data is completely synchronized with your source every once in a while.
### Check your new source!
1. Click **Next** to finalize the setup. Once completed, you'll receive confirmation that your new source is set up!
2. You can view your new source on the [Sources](https://app.nekt.ai/sources) page. Now, for you to be able to see it on your [Catalog](https://app.nekt.ai/catalog), you have to wait for the pipeline to run. You can now monitor it on the [Sources](https://app.nekt.ai/sources) page to see its execution and completion. If needed, manually trigger the pipeline by clicking on the refresh icon. Once executed, your new table will appear in the Catalog section.
> If you encounter any issues, reach out to us via Slack, and we'll gladly assist you!
## Available streams
Sults only offers a date filter on two endpoints, so `tickets` and `checklist_evaluations` sync
**incrementally** and every other stream is a full table.
### Units
| Stream | Description |
| ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `companies` | Franchise units with their legal data, addresses, implementation and inauguration dates, federal tax registry data, groups, and custom forms. Both active and inactive units are synced. |
| `people` | People registered against the units, with their role and qualification per unit, contact details, and custom fields. |
### Tickets
| Stream | Description |
| ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `tickets` | Support tickets with requester, assignee, unit, department, subject, deadlines, satisfaction score, and interaction counts. Incremental on the last change date. |
| `ticket_timeline` | Full history of each ticket: interactions, deadline changes, assignee and subject changes, support people added or removed, and conclusion. |
### Checklists
| Stream | Description |
| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------ |
| `checklist_evaluations` | Field audits carried out on the units, with template, evaluator, scores, and deadline. Incremental on the evaluation end date. |
| `checklist_answers` | Every question and answer of each evaluation, with section, answer type, score, comment, and attachments. |
| `checklist_checkins` | Check-in of each evaluation, with geolocation, device user agent, digital signatures, and attachments. |
| `checklist_checkouts` | Check-out of each evaluation, with the same detail plus the people the result was shared with. |
| `checklist_action_plans` | Action plans opened from a non-conforming answer, with the 5W2H fields, cost, owner, and conclusion. |
| `checklist_action_plan_interactions` | Comments, status changes, deadline changes, and attachments recorded on each action plan. |
### Expansion
| Stream | Description |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `deals` | Franchise sales pipeline: deals with funnel and stage, source, campaign, temperature, contacts, investment value, loss reason, and time spent in each stage. |
| `deal_timeline` | Activities, notes, attachments, emails, checkpoints, assessments, and stage changes recorded on each deal. |
### Projects and implementation
| Stream | Description |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| `projects` | Projects with template, category, owner, unit, planned and actual dates, team, and labels. |
| `project_tasks` | Tasks of each project, with phase, owner, priority, status, completion percentage, subtasks, predecessors, and comments. |
| `implementation_projects` | The same structure for the projects that track the rollout of new units. |
| `implementation_tasks` | Tasks of each implementation project. |
### Announcements
| Stream | Description |
| ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `announcements` | Announcements published to the network, with category, author, publication window, audience, and whether reading is mandatory. Both active and inactive announcements are synced. |
| `announcement_contents` | Body and attachments of each announcement. |
| `announcement_users` | Per-user delivery status: whether the announcement was opened, when, and whether it was acknowledged. |
### Purchasing
| Stream | Description |
| ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `purchase_orders` | Orders placed by the units with their suppliers, including workflow stage, totals, payment and shipping method, and shipping address. Cancelled orders are synced too. |
| `purchase_order_products` | Line items of each order, with quantity, price, discount, and chosen variant options. |
| `purchase_order_stages` | Stages of the purchase order workflow. |
| `products` | Purchasing catalogue, with category, supplier, availability date, variation axes, and images. Both active and inactive products are synced. |
| `product_variants` | Concrete variants of each product, one per combination of variation options. |
| `product_prices` | Price, list price, minimum order rules, and purchase limits per product and supplier. |
| `product_stocks` | Stock available per product, supplier, and variant, with the expected restock date. |
| `product_assortments` | Product assortments (mixes) configured in the purchasing module. |
| `product_assortment_products` | Products included in each assortment, with their supplier. |
| `product_assortment_companies` | Units each assortment is made available to. |
## Notes and limitations
* **Inactive records.** Sults hides inactive records from its listings by default. The connector
explicitly asks for both flavors on units, products, announcements, order stages, and assortments,
and for both cancelled and non-cancelled purchase orders, so closed units and delisted products
still reach your catalog. The people endpoint has no such filter: Sults returns only active people
linked to an active unit.
* **Evaluations in progress.** `checklist_evaluations` is incremental on the evaluation end date,
which Sults leaves empty while an audit is still open. Open evaluations are picked up on the first
sync and again once they are concluded, but their intermediate updates are not tracked. Schedule an
additional full sync if you need open audits to stay current.
* **Detail streams cost one request per parent record.** Ticket and deal timelines, checklist
answers, check-ins, check-outs, action plans, and product prices and stock are read one parent at a
time. On large accounts, select only the ones you need to keep the pipeline fast.
* **Rate limits.** Sults publishes no rate limit. The connector honors any slow-down response the API
returns and retries with backoff, so a throttled run gets slower rather than failing.