# Welcome We believe service desks should do more than resolve requests—they should drive business impact. At Siit, our mission is to build an AI-powered service desk that unifies operational data and empowers organizations to identify what's holding them back and what could accelerate their success. We're moving beyond ticket closure to deliver autonomous resolution and strategic intelligence that turns IT service management from a cost center into a competitive advantage. {% embed url="" %} {% hint style="info" %} Want to jump right into setting up Siit? Check out our [Quickstart](/getting-started/quickstart) {% endhint %}
:bolt-lightning:Quickstart/pages/7FvWQMF0kTK7HGhlQfmo
:ticket:Core Plateform/pages/i73g4LZQanoLj7XtSO18#overview
:robot:AI/pages/GHqSuia8UW7bMeHjHabl
:plug-circle-check:Integrations https://www.siit.io/integrations
:code-simple:Developerhttps://developer.siit.io/
:square-rss:Changeloghttps://www.siit.io/changelog
# Quickstart > Goal: create and resolve your first Access request from Slack/Teams, then turn it into an automated workflow ### Minute 0–2: Install Siit in Slack or Microsoft Teams {% content-ref url="/pages/3DBkm0PqS2BmkJMziY4P" %} [Connect Slack](/getting-started/connect-slack) {% endcontent-ref %} {% content-ref url="/pages/0YlhNc1S76jnuRZ7eClB" %} [Connect Microsoft Teams](/getting-started/connect-microsoft-teams) {% endcontent-ref %} ### Minute 2–4: Submit your first request In Slack/Teams, open the Siit app and choose “New request.” * Pick “App Access” service. * Submit. You’ll see a request thread and an inbox card created.
### Minute 4–6: Resolve it once manually (see the flow) * Open the [request](https://app.siit.io/) in the admin console. * Review the side panel: requester, apps, devices (if any), prior access. * Add a note, assign to yourself, set status to Resolved. Outcome: you’ve validated end‑to‑end request flow ### Minute 6–8: Connect your IAM and HRIS In Settings → Integrations, connect one IdP: * IAM : Okta, Entra ID, Google Workspace, or JumpCloud... * HRIS : Hibob, Bamboohr, workday...
### Minute 8–10: Invite your teammates * Invite your teammate (Settings → Teammates) and assign them their roles. ### :track\_next: Next steps (recommended) * Enable the first Workflows → Templates → “Access request – add to group/license.” * Add Knowledge sources (Notion, Confluence, Google Drive) with RBAC retrieval and redaction. * Enable AI Suggest articles for FAQs. # Connect Slack Goal: connect Slack so employees can submit requests in chat and admins can work from threads and the Siit inbox. ### Prerequisites * Slack workspace admin privileges, or approval from an org admin if your directory requires it * Siit admin access * If your Slack is Enterprise Grid: know which workspaces need the app enabled ### Step-by-step 1. **Start the install** * In Siit: [Settings → Integrations](https://app.siit.io/settings/integrations/apps) → Slack → Connect * You’ll be redirected to Slack’s permission screen
2. **Approve permissions** * Review and click *Allow*. Scopes shown by Slack may include: * commands (slash and global shortcuts) * chat:write (post updates to threads) * users:read, users.profile:read (map Slack users to Siit People) * channels:read, groups:read (list public/private channels you add the bot to) * im:write (bot DMs) Note: exact scopes depend on features you enable; Slack displays the current list before install.
3. **Enable request creation** * Siit App : App Home: Open the Siit app in Slack → “New request” * Message action: From any message, “More actions …” → “Create a Siit request” * Optional channel: * Create or choose a channel (e.g., #ask-it) * Invite the bot: /invite @Siit * Pin a message with “Start a request via the Siit shortcut” so employees know how to submit 4. **Test your first request** * Use the siit App → pick the service “App Access” → Submit * You’ll see a thread in Slack; the request appears in the Siit inbox * Reply in thread. ### **Post-install recommended setup** * Rename the App * Create a #siit-test channel for internal dry runs * Share a short announcement with the shortcut link and when to use Siit vs ad-hoc DMs
{% hint style="info" %} Enterprise Grid notes * Install to each workspace that should submit requests * If your org restricts apps, ask a Slack Org Admin to approve Siit in the App Directory, then repeat the install per workspace {% endhint %} # Connect Microsoft Teams Connect Microsoft Teams so employees can submit and follow requests directly from Teams—without switching tools or losing context. ### Step by step - **How to connect the integration** #### **Step 1: Connect from Siit** 1. In your Siit admin console, go to **Settings → Integration library** 2. Find **Microsoft Teams** and click **"Connect Now"** 3. Sign in with your Microsoft account when prompted 4. Review and accept the permissions Siit requests
#### **Step 2: Install the Siit app in Teams** 1. Go to the [Siit app in Microsoft Marketplace](https://teams.microsoft.com/l/app/0d4395d7-62b5-4240-aa68-a70e2b46676c) 2. Click **"Get it now"** 3. Follow the prompts to add it to your Teams instance {% embed url="" %} **Verify it's working:**\ Open the Siit app in Teams and ensure the **"Portal"** tab loads properly.
*** #### **Test your first request** 1. In Teams, open the **Siit app** 2. Pick a service (e.g., "App Access") and submit 3. You'll see a Teams thread created; the request appears in the Siit inbox 4. Reply in the thread and confirm the conversation syncs in Siit {% embed url="" %} **You're all set** 🎉 # Set Live Move from sandbox to production so employees can submit requests in Slack/Teams, Email, Portal and admins can resolve with automation. ### Rollout plan at a glance 1. **Pick your pilot scope (start with IT, for example):** * Access: group/license changes in your IdP and apps * Password/MFA reset with guardrails * Equipment * Onboarding/Offboarding **2. Define your Services** * Name and describe each service so employees know when to use it. * Add forms and required fields; set requester visibility and sensitive-data rules. * Map each Service to a category and default assignee or queue.
**3. Configure channels** * Slack or Teams bot installed and visible to employees. * Email capture address selected (e.g., [help@yourcompany.siit-mail.com](https://platform.openai.com/chat/edit?prompt=pmpt_68ecfa97c12c81969b6f4fca57c1a3d709fe727603dab985\&version=1)) * Portal URL and branding set (e.g., [https://yourcompany.siit.io](https://yourcompany.siit.io/))
**4. Set up your Inbox** * Create agent group(s) for pilot (e.g., IT Tier 1) and add backup owners. * Define assignment rules for pilot Services and a fallback queue. * Configure working hours & confirm SLA policies.
**5. Turn on top workflow(s)** * Access automations: add/remove groups or assign licenses. * Password/MFA reset: add approvals and requester verification. * Hardware requests: approval + fulfillment checklist, asset handoff. * Approvals: ensure manager lookup and escalation rules work.
**6. Activate AI Agents** * Enable AI triage and suggested replies for pilot Services. * Optionally allow AI to auto-resolve low-risk, well-documented issues. * Review guardrails and confidence thresholds.
7. **Validate end-to-end (pre-flight checklist below)**
8. **Announce your pilot** * Send a short heads-up in Slack/Teams. * Follow with a full rollout message via email or #general.
9. Monitor week‑1 KPIs daily (see targets below)
10. Iterate, then go wide to additional teams and services :rocket:
### Success metrics for week 1 * Time-to-first response: under 4 business hours * Time-to-access: 35% faster vs your baseline * Channel adoption: 60–80% of requests created in chat (Slack/Teams) * Automation assist rate: at least 25% of resolves use workflows/AI ### Ready-to-send announcements Short announcement > Hi everyone! > > We’re now using Siit to submit and track your requests in one place: > > * Request software access > * Ask for a new computer or accessory > * Reset password/MFA > * Report IT issues > * ... > > \ > Why: Siit keeps everything organized and speeds up responses. You’ll see status updates as your request moves forward. > > How to use it: > > * In Slack/Teams: open Siit and send your request in DM > * Or mention @Siit in this channel for non-sensitive requests > * Email also works: [help@yourcompany.siit-mail.com](https://platform.openai.com/chat/edit?prompt=pmpt_68ecfa97c12c81969b6f4fca57c1a3d709fe727603dab985\&version=1) > * Prefer a portal? [https://yourcompany.siit.io](https://yourcompany.siit.io/)
> > That’s it! Please reach out if you have questions. **Full rollout announcement** > Subject: New way to submit your requests with Siit 🚀 > > \ > Hi everyone, > > We’re moving requests to Siit so we can respond faster, stay organized, and keep you informed. > > Good news: keep using Slack/Teams or Email—no new account needed. > > How to create a request > > * Slack/Teams > > 1. Search for “Siit” and open the app > > 2. Add it as a favorite for quick access > > 3. Send your request in DM and follow the prompts > > 4. For non-sensitive topics, you can @Siit in channel > > * Email Send to [help@yourcompany.siit-mail.com](https://platform.openai.com/chat/edit?prompt=pmpt_68ecfa97c12c81969b6f4fca57c1a3d709fe727603dab985\&version=1) > * Portal Visit [https://yourcompany.siit.io](https://yourcompany.siit.io/) for forms, status, and FAQs > > Examples > > * How do I use my learning budget? > * Can I get a new laptop or monitor? > * I’d like to update my bank details > * Access to \[App Name] > > Please submit requests through Siit. It helps us help you—faster and with better visibility. > > Questions or feedback? Reply here or check the FAQ to learn more about Siit. > > \ > Thanks, The Team # Request Management Track, manage, and act on all your requests in a single place.
{% stepper %} {% step %} ### Overview A Request in Siit represents an employee need—from “I can’t sign in” to “Grant access to Salesforce” to “Onboard a new colleague.” It captures all the context, stakeholders, approvals and tasks in one place and moves through a clear lifecycle from intake to resolution. Whether the request starts in Slack, Teams, the web portal, email, or the API, it behaves the same, with a single timeline and SLA. {% endstep %} {% step %} ### Explore all the core features of requests management {% endstep %} {% endstepper %} {% content-ref url="/pages/SZ5w8WkCdGS3Biw5YFbX" %} [Views](/request-management/views) {% endcontent-ref %} {% content-ref url="/pages/QpNrTkVb99khWG1i8Mga" %} [Request conversation](/request-management/request-conversation) {% endcontent-ref %} {% content-ref url="/pages/1TbYo2uq5oqghqhi0goW" %} [Side panel](/request-management/side-panel) {% endcontent-ref %} {% content-ref url="/pages/mO1PAHCbjL5kOfVkKzi4" %} [Assignment](/request-management/assignment) {% endcontent-ref %} {% content-ref url="/pages/wgIqWXYFzfe2AWmbev60" %} [Approvals](/request-management/approvals) {% endcontent-ref %} {% content-ref url="/pages/PwQmAj8B7c4h0MmJCPWd" %} [Tags](/request-management/tags) {% endcontent-ref %} {% content-ref url="/pages/fMyiCYVdGeBI3p1jrAGJ" %} [Message templates](/request-management/message-templates) {% endcontent-ref %} {% content-ref url="/pages/r7RWx0jr57cVDYyb7bAD" %} [Public vs Private requests](/request-management/public-vs-private-requests) {% endcontent-ref %} # Service catalog {% stepper %} {% step %} ### Overview The Service Catalog is where you define every service your teams offer to employees—access requests, new equipment, payroll questions, onboarding, and more. Each service comes with its own look and feel, routing rules, SLAs, forms, audience permissions, and analytics. When employees pick a service in Slack/Teams or the portal, Siit applies everything you configured so requests are consistent and fast.
{% endstep %} {% step %} ### Organize by Category Categories keep your catalog tidy and power reporting. Use broad groups like: * IT: Access, Devices, Network, SSO * People/HR: Onboarding, Offboarding, Payroll * Finance: Expense, Vendor, Purchasing * Security and Legal: Data access, Incident, Contract Enable/disable services without deleting them, and reorder to surface the most used items first. {% endstep %} {% step %} ### Explore all the core features of {% endstep %} {% endstepper %} {% content-ref url="/pages/VwjsUtBZZ9BnTKXMUmBP" %} [Service overview](/service-catalog/service-overview) {% endcontent-ref %} {% content-ref url="/pages/eHw1xIQC9i3Eic1JsmCI" %} [Service Catalog](/service-catalog/service-overview) {% endcontent-ref %} {% content-ref url="/pages/8DMd51bITOwaYi0qFh3V" %} [Service forms](/service-catalog/service-forms) {% endcontent-ref %} {% content-ref url="/pages/Ymu6IhE4ymFo9UyahJVl" %} [SLAs](/service-catalog/slas) {% endcontent-ref %} {% content-ref url="/pages/F5GNlQwzDAJFhPjZkkQU" %} [Audience & visibility](/service-catalog/audience-and-visibility) {% endcontent-ref %} {% content-ref url="/pages/hfsHsN00t65sBwScqd43" %} [Self service portal](/service-catalog/self-service-portal) {% endcontent-ref %} # AI Siit’s AI features are built to save minutes on every request while keeping humans in control. You decide what data AI can use, when it can act, and which steps require explicit approval. Every suggestion and action is auditable. {% content-ref url="/pages/vMWgzWh1GwYOEu8NTvcN" %} [AI trust model](/ai/ai-trust-model) {% endcontent-ref %} ### What AI can help with **Autonomous Request Resolution** * Automatically resolve common IT requests like password resets, software access, and account provisioning without human intervention * Execute actions across multiple connected systems (Active Directory, MDM, HRIS, etc.) from a single request **Intelligent Workflow Automation** * Automate complex, multi-step workflows that adapt based on employee role, department, request history, and system state * Go beyond simple if/then rules with AI that understands context from your unified data * Chain actions across IT, HR, and Finance and other internal systems in a single automated workflow * Pull data from any integrated tool and take action based on unified operational context **Smart Compose** * Draft clear, on-brand replies that pull from your knowledge base and cite similar past requests * Include the right resolution steps based on request context and historical data * Rewrite, shorten, lengthen, change tone, or translate responses as needed * Review AI-generated responses and accept, edit, or discard before sending **Intelligent Triage** * Automatically categorize, assign, and prioritize requests based on content, service type, and requester attributes * Suggestions improve over time as AI learns from your team's decisions * Automate triage entirely via workflows when AI confidence is high enough **Thread Summarization** * Condense long request threads into crisp handoffs and status updates * Ensure context is never lost when requests move between team members or shifts * Generate clear summaries for reporting and audit trails **Resolution Learning** * Convert resolution outcomes into clean, reusable resolution notes * Improve knowledge base search and self-service deflection over time * Help AI provide better suggestions for future similar requests ### Explore Siit AI agents {% content-ref url="/pages/4oVJ6LnPZPXbfnCNLi9A" %} [Triage Agent](/ai/triage-agent) {% endcontent-ref %} {% content-ref url="/pages/OlryuObeb41k838DG7O3" %} [IT Agent](/ai/it-agent) {% endcontent-ref %} # Workflows {% stepper %} {% step %} ### Overview Automate routine requests and free your team for work that requires expertise. Siit Workflows let you route, approve, provision, notify, and update requests using a visual, no-code builder. Use workflows to resolve straightforward requests instantly, accelerate complex resolutions, and orchestrate recurring processes like onboarding and offboarding. {% endstep %} {% step %} ### The table view The workflow table is your control room. It lists every automation with status, trigger, category, ownership, and activity. * Status chips: Live, Paused, Draft. Toggle as you test and roll out safely. * Filters and search: filter by status, trigger type, category, last updated, created by, and more. * Categories: group related workflows (IT Access, HR, Security). Categories can also be used in roles & permissions to limit who can view or edit a set of workflows. * Activity: see “Total enrolled” to understand how often a workflow runs. * Manage categories and create new workflows from the toolbar. * Run History : * **Branch column** : each run row shows which branch the workflow took, so you can see at a glance which path ran. * **Clickable request ID** : click a request ID in the history to open that request in a new tab, without leaving the table. {% endstep %} {% step %} ### Build visually (no code) Design the flow on a canvas. Read and manage complex automations at a glance. * Drag‑and‑drop steps. Zoom, pan, and re‑order easily. * Branching with Paths. Split the flow based on conditions (e.g., “If app = Okta → provision; else → create Jira ticket”). * Draft → Live → Pause lifecycle with a single toggle. * Each step shows a summary (e.g., “Set status: New”). Open to edit details when needed. {% endstep %} {% step %} ### Explore all the core features of requests management: {% endstep %} {% endstepper %} {% content-ref url="/pages/tHhvtaXSTn4KFBVD3s4M" %} [Triggers overview](/workflow/triggers-overview) {% endcontent-ref %} {% content-ref url="/pages/j0i39NN63GjwjxdmY3IX" %} [Actions library](/workflow/actions-library) {% endcontent-ref %} {% content-ref url="/pages/sFbxIlnts3aXpmbiFGoI" %} [Branching & approvals](/workflow/branching-and-approvals) {% endcontent-ref %} {% hint style="info" %} You can also add images simply by copying and pasting them directly into the editor — and GitBook will automatically add it to your file manager. {% endhint %} # Objects and Data model {% stepper %} {% step %} ### Overview Siit’s data model unifies three core objects—People, Applications, and Equipment—so every request carries the right context. This foundation powers routing, approvals, automation, audience targeting, and reporting. Connect your sources of truth (IdP/HRIS/MDM), choose which fields matter, and work from a single, consistent view. {% endstep %} {% step %} ### How these objects power requests and automation ⚙️ Requests * See requester info, recent requests, assigned apps and devices, and SLA—all in one place. Make decisions without switching tabs. Service Catalog * Use People groups (department, location, legal entity) to define who can see and submit each service. * Add “Select application” or “Select device” form fields so employees provide precise context. Workflows * Conditions can check requester attributes (e.g., Department = Sales), app ownership (App owner = Security), or device state (Lifecycle = Outdated). * Actions can provision/deprovision access, add to groups, or open tickets in Jira/Linear based on app or requester data. {% endstep %} {% step %} ### Governance and privacy 🔒 * Field‑level visibility: hide sensitive fields (e.g., compensation) from most roles. * Source priority: select which integration is the source of truth for each field. * Roles & permissions: restrict who can view/edit People, Applications, and Equipment data. {% endstep %} {% step %} ### Explore all the objects {% endstep %} {% endstepper %} {% content-ref url="/pages/I75RKm06EMgODC6TINY1" %} [People](/data-management/people) {% endcontent-ref %} {% content-ref url="/pages/rtBtYTtyUvxFnJ65oZti" %} [Apps](/data-management/apps) {% endcontent-ref %} {% content-ref url="/pages/mYLLm4OLAWjamKfQd2EJ" %} [Equipment](/data-management/equipment) {% endcontent-ref %} {% content-ref url="/pages/ahKUJCL4Cv8aGzqfjd6h" %} [Articles](/data-management/articles) {% endcontent-ref %} # Channels Meet employees where they already work. Siit unifies four channels—Slack, Microsoft Teams, Email, and the Web Portal.
:slack: SlackSlack-first ticketing for modern teams/pages/w0mkqeqZYf44gRyvawDm
:windows: Microsoft TeamsTeams-native ticketing system/pages/70J1ibPQd64qIu27HcAy
:envelope-open: EmailSubmit requests via email/pages/vg55shrQkf4MWjAnRaFw
:window: Self service PortalProtect your docs and require sign-in/pages/hfsHsN00t65sBwScqd43
# Slack Connecting Slack to Siit enables powerful & automated help desk functionality, and seamless request management directly from your Slack workspace. Run your service desk inside Slack. Capture, triage, and resolve requests in-thread, with AI deflection, two-way sync, and full context attached, so your team handles every ask without leaving the conversation.
Siit allows you to submit and manage service requests directly in Slack. Siit's native Slack integration keeps everyone informed on status without ever having to leave Slack.
### Submit a new request Employees can create requests in multiple ways: ⭐️ **Mention @Siit in a public channel**\ Tag Siit in any public channel to create a request that's visible to the team. ⭐️ **Write a DM to Siit**\ Send a private message to Siit to create a confidential request. ⭐️ **Use Slack actions**\ Right-click any message in a private channel or DM and select "Create a ticket" from the actions menu.
[Learn how to submit requests in Slack →](https://help.siit.io/slack-requests) *** ### Stay up-to-date about your requests Siit keeps you informed with automatic updates: * **Thread notifications**: Receive updates about status changes, assignments, and resolutions directly in your request thread * **Status overview**: Click on the request title to see the full status and details at any time * **Real-time sync**: All updates from admins are instantly reflected in Slack
*** ### AI Agents: Instant answers from your knowledge base Siit AI Agents provide instant, accurate answers based on your existing documentation from Notion or Confluence—no waiting required. #### How it works When employees ask questions in Slack: 1. Siit AI searches your connected knowledge bases 2. Generates contextual answers with source references 3. Delivers responses in seconds, directly in the thread {% embed url="" %} *** ### Turn any message into a ticket Need to convert a conversation into a tracked request? Admins can easily transform any Slack message into a Siit ticket: * **From public channels**: Right-click any message and select "Create ticket from message" * **From DMs**: Convert employee questions into trackable requests with full context preserved * **Automatic linking**: The original message thread stays connected to the ticket
*** ### Private notes for internal collaboration Admins can add private notes to requests that only other admins can see, perfect for: * Internal discussions about resolution strategies * Sensitive information that shouldn't be shared with requesters * Coordination between team members Use the 🔒 emoji in the admin notification thread to create a private note.
**Learn more about how to** [Give functionality to Slack emojis](https://help.siit.io/slack-emoji-actions) *** ### Getting started Ready to connect Slack to Siit? {% content-ref url="/pages/3DBkm0PqS2BmkJMziY4P" %} [Connect Slack](/getting-started/connect-slack) {% endcontent-ref %} # Microsoft Teams Siit brings powerful service desk functionality directly into Microsoft Teams, eliminating the need to switch between tools and making it effortless for employees to get help.
Siit allows you to submit and manage service requests directly in Microsoft Teams. Siit's native integration with Teams, Microsoft 365, and Outlook enables you to turn direct messages into requests and keeps everyone informed on status without ever having to leave Teams.
### Submit a new request Employees can create requests in multiple ways: ⭐️ **Message the Siit bot**\ Start a direct conversation with Siit to create a private, confidential request. ⭐️ **Use message actions**\ Right-click any message in Teams and select "Create a ticket" to instantly transform conversations into traceable requests. ⭐️ **Use adaptive cards**\ Fill out dynamic, context-aware forms directly in Teams to provide all necessary details upfront. {% embed url="" %} *** ### Stay up-to-date about your requests Siit keeps you informed with automatic updates delivered right in Teams: * **Direct notifications**: Receive updates about status changes, assignments, and resolutions in your conversation with Siit * **Status cards**: View the full request status and details through interactive adaptive cards * **Real-time sync**: All updates from admins are instantly reflected in Teams
*** ### 🤖 AI-powered automation Siit's AI capabilities help streamline your service desk operations with intelligent automation: #### AI Agents: Instant answers from your knowledge base Siit AI Agents provide instant, accurate answers based on your existing documentation from Microsoft 365, SharePoint, or other connected knowledge bases—no waiting required. **How it works:** 1. Employees ask questions in Teams 2. Siit AI searches your connected knowledge bases 3. Generates contextual answers with source references 4. Delivers responses in seconds, directly in the conversation {% content-ref url="/pages/NBF1pRgz7YgjGQwMbhOy" %} [AI](/core-plateform/ai) {% endcontent-ref %} *** ### 🔖 Dynamic forms for better context Create personalized dynamic forms to capture essential information upfront, reducing back-and-forth communication: * **Conditional fields**: Show or hide fields based on previous answers * **Rich input types**: Text, dropdowns, multi-select, date pickers, and more * **Microsoft 365 integration**: Auto-populate fields with user data from Azure AD * **Mobile-friendly**: Forms work seamlessly on Teams mobile apps
*** ### Turn any message into a ticket Need to convert a conversation into a tracked request? Transform any Teams message into a Siit ticket with full context preserved: * **From chats**: Right-click any message and select "Create ticket from message" * **From channels**: Convert team discussions into trackable requests * **Automatic context**: The original message thread stays connected to the ticket *** ### Getting started Ready to connect Microsoft Teams to Siit? {% content-ref url="/pages/70J1ibPQd64qIu27HcAy" %} [Microsoft Teams](/core-plateform/integrations/microsoft-teams) {% endcontent-ref %} # Self service portal The Portal is your company’s self‑service home for internal resources. Employees can submit and track requests, find apps, browse the directory, and read knowledge—everything in one place. Admins brand and control access from Settings.
### Accessing the Portal * URL: yourcompany.siit.io * Sign‑in: Microsoft 365 or Google or SAML (same identity you configured in Siit) * Entry points: link from Slack/Teams, Web, or Admin console ### What employees see **My Requests** * Request history, Followed requests, Pending approvals, AI conversations (if enabled) * Search, filter by status, sort by date * Open a request to reply, attach files, or add participants **Services Catalog** * Browse categories (IT, HR, Finance, etc.) and open a service form to submit a request * Visibility honors service audience rules set by admins **App Library** * Find company tools by category, search, and mark favorites **Directory** * Search colleagues; see title, department, manager, and location **Knowledge Base** * Search and browse articles; open guides directly from results ### Create and manage a request
**+ Create** * Click Create a request (top right) or open a service from the Services Catalog * Fill the form, attach files, submit **Track and act** * My Requests shows status for open/closed items and those you follow * Reply to agents, add info, upload attachments * Approvals assigned to you appear under Pending approvals—Approve/Reject in one click ### AI in the Portal (Pro plan)
If enabled, employees can: * Ask questions in the search bar or AI conversations tab and get instant answers from your knowledge * Turn an AI exchange into a tracked request when human help is needed Admins control availability and guardrails in [Settings → Portal → AI](https://app.siit.io/settings/channel/portal) ### Admin setup
1. **Settings → Portal** * Settings: Portal name, domain, logo, and cover image; Set live when ready * Navigation: show/hide and reorder My Requests, Services, App Library, Directory, Knowledge * AI: toggle AI assistant and configure sources/permissions * Survey: enable CSAT after resolution * Audience: choose who can access the Portal (all employees or specific groups)
2. **Publish content** * Services: configure forms, routing, SLAs, and audience; mark visible in Portal * Knowledge: create categories and articles; set visibility * App Library: organize apps by category and ownership #### What to expect * A single, branded destination for help * Fewer back‑and‑forths thanks to service forms and knowledge suggestions * Consistent tracking: requests created in the Portal sync with Slack/Teams conversations and the Siit inbox #### Best practices * [ ] Pin the Portal link in Slack/Teams and your intranet * [ ] Feature 6–10 most requested services on the Services page * [ ] Keep forms short; ask only what’s needed to start * [ ] Use Knowledge for common “how‑to” and policy questions; refresh monthly * [ ] Enable AI when your knowledge base is ready to deflect simple requests # Email ### Submit requests via email
#### How it works **Your team's email address:**\ If your organization is Acme and you want to submit a request to your IT team, simply send an email to: ``` [team-name]@acme.siit.io ``` For example: `it@acme.siit.io` or `hr@acme.siit.io` **What happens next:** 1. Your email is received by Siit 2. A new request is automatically created 3. You receive a confirmation with your request details 4. The appropriate team is notified and can start working on your request Learn [how to submit requests via email ](https://help.siit.io/email-request) *** ### Add information to existing requests Need to provide more details, ask a follow-up question, or just let the team know they're doing an awesome job? Simply reply to any email update you receive from Siit. #### Reply to updates When you reply to a Siit email notification: * Your message is automatically added to the request thread * The assigned team members are notified * All context is preserved in one place * No need to log into any platform *** ### Configure email sending Siit offers two options for sending emails on behalf of your company domain. Each has its own benefits and considerations. #### Option 1: Individual email address verification **Best for:** Quick setup, small teams, or testing Personalize both the "From" name and email address with this simple implementation: **Setup steps:** 1. **Provide information:** Enter your desired "From" name and email address in Siit's Email settings 2. **Verify your address:** You'll receive a verification email from Postmark 3. **Confirm:** Follow the verification steps in the email to confirm your address 4. **Start sending:** Once verified, Siit can send emails from your address **✅ Benefits:** * ⚡ Quick and easy setup * No DNS configuration required * Perfect for individual users or small teams **⚠️ Considerations:** * Each sending email address needs individual verification * May affect email deliverability compared to domain authentication * Recipients might see "via postmarkapp.com" tags in Gmail * Outlook may show "on behalf of" indicators *** #### Option 2: Fully-authenticated domain (Recommended) **Best for:** Organizations prioritizing deliverability, brand consistency, and professional appearance Authenticate your entire company domain for a fully-branded, secure email experience. **Setup steps:** **1. DNS Record Setup** Add specific DNS entries to your domain configuration to verify ownership. You'll need to add these records (provided by your Siit CSM): * **DKIM record:** Authenticates that emails are genuinely from your domain * **Return-Path record:** Improves deliverability and tracking * **Custom tracking domain (optional):** For branded link tracking **2. Reach out for approval** Contact your Siit Customer Success Manager to approve and activate the domain once DNS records are configured. **3. Verification** Siit will verify your DNS setup and confirm when your domain is ready to use. **✅ Benefits:** * 🚀 **Superior deliverability:** DMARC alignment and domain reputation * 🎯 **Professional appearance:** No "via" or "on behalf of" tags * 🔒 **Enhanced security:** Full SPF, DKIM, and DMARC authentication * 📊 **Better analytics:** Complete visibility into email performance * ✨ **Consistent branding:** All emails appear directly from your domain **⚠️ Considerations:** * Requires DNS configuration access * Initial setup takes longer than individual verification * Needs coordination with IT or domain administrator
# Views Your Views are the control tower for all work. Out of the box you’ll see My open, Unassigned, Team, and All. Each view can be filtered by status, priority, service, requester attributes, channel, SLA state, tags, assignee, and more. Save any combination as a custom view and share it with a team, or make it your personal default. Columns are configurable so you can surface what matters—SLA clocks, services, Channel, or Inbox—and hide the rest. Views are live. Activity updates in real time, with SLA at‑risk requests visually highlighted. Bulk select lets you reassign, add tags, change status across many requests at once. ### What you’re looking at All requests in one place * The table lists every request you can see, with real‑time updates. Sort by Created at or Last updated, and scan key fields like Channel, Status, Priority, Tags, Inbox and Assignee.
### Display controls * Click Display to choose between List and Board, pick the sort order, and turn columns on/off. Columns include Channel, Priority, Inbox, Assignee, Associated to (service), Tags, Rating, Created at, Last updated, Followers/Participants, SLA, and ID. * Use only the columns you care about; Siit remembers your choice for that view. * \[Screenshot: Display menu with column chips]
### Powerful filters * Add filters from the bar at the top. Common filters: Status, Priority, Inbox (team/queue), Assignee, Participants, Requester, Associated to (service/category), Tags, Rating, Snooze, Approval pending, Read / Unread and any custom fields like Office location. * Filters are chip‑based and multi‑select. Combine several (e.g., Status is any of New/In progress + Inbox = IT Ops + SLA at risk).
### Create and manage Views * Save your setup * Once your filters, sort, and columns look right, click All views → Add to save as a new view. Give it a name and choose who can use it. * Choose who sees it * Private: only you. * Shared with inbox: visible to members of a specific inbox/team. * Everyone: available to all agents. * Organize your Views * Reorder Selected views, set your default, or remove ones you don’t need. Standard Views (Open, New, Waiting, Pending approval, Snoozed, Closed) are always available.
*Note that* [*Group Requests*](/request-management/group-requests) *appear in any view where at least one child matches the filter, and that the children of a group stop appearing on their own.* ### Board view * Visual flow * Switch to Board to see requests grouped by status (e.g., New, In progress, Waiting, Resolved). Each card shows the essentials: requester, priority, status, service, ID, channel, inbox, assignee, and SLA badges. * Work by dragging * Drag a card to another column to update status. Open a card for full details, or use quick actions on the card (assign to me, change priority, add note). * Same filters, different layout * The board respects the same filters and sharing rules as the list. Perfect for stand‑ups or live swarms.
# Request conversation Every request has a single conversation timeline that keeps the full story in one place—agent replies, internal notes, approvals, status/SLA updates, and workflow events. Messages sync to the requester’s original channel (Slack or Microsoft Teams) and to the Portal.
### What you can do in the request conversation * Reply: send a public message to the requester in Slack/Teams and the Portal. Attach files, use @mentions, and preview before sending. * Internal note: add private context for agents/admins only. Great for handoffs, troubleshooting, and coaching. * Approval: request sign‑off from one or more approvers. Statuses (Pending, Approved, Rejected) are tracked in the timeline and the sidebar. * Message Templates: insert reusable answers with variables to personalize at scale. #### Message reply box * Type selector (left): choose Reply, Internal note, or Approval. * Composer: supports attachments, mentions, emojis, and templates. * Preview: review before sending (public replies and approvals). #### Replies * Channel aware: goes to the requester where they started (Slack/Teams), and to the Portal. * Files: upload documents, images, or links; everything is mirrored to the request. * Articles: access your entire knowledge base to share articles * Mentions: @colleagues to bring them in; they become participants and get notified. #### Internal notes * Visibility: only agents/admins can see notes; requesters never do. * Uses: capture investigation steps, share context across shifts, or coach teammates. * Mentions: notify teammates without pinging the requester. #### [Approvals](/request-management/approvals) * How it works: pick approver(s), add context (or use a template), and send. Approvers can act from Slack/Teams or the Portal—no extra license needed. * States: Pending → Approved/Rejected. All decisions are logged in the timeline with who, when, and any comment. * Templates: prefill the message and include dynamic variables (approval\_link, requester.first\_name, app.name, etc.). * Automate: trigger workflows on Approved/Rejected (e.g., change status, assign, kick off provisioning, notify requester). #### [Message templates](/request-management/message-templates) * Purpose: keep answers fast and consistent; update centrally when policy changes. * Variables: personalize with fields like requester.first\_name, requester.manager, service.name, app.name, approval\_link, and more. * Organization: group templates by team or service for easy discovery. * Access: choose templates from the composer; admins manage them in Settings. #### [The side panel (Details)](/request-management/side-panel) * Request details: status, assignee, service, priority, tags, SLA timers, Snooze/Resolve. * People info: requester profile (title, manager, department, location, contacts). * Integrations: quick actions to connected systems (e.g., Okta, Google/Azure, MDM) when available. * Context: related requests, assigned equipment, active apps. * Approvals: current approval(s) with state and actions. * Deep links: clicking people, devices, or apps opens their dedicated pages for full context. # Group Requests Group Requests let you handle a set of related requests as one. Reply once and the message reaches every requester in their own thread. Reassign or change priority on the group and Siit applies the update to every request inside it.
### Why Group Requests matter * One reply, many requesters: answer an outage, an office closure, or a policy change once and every affected requester gets the update. * One coordinated action: reassign, reprioritize, resolve, snooze, tag, or change service across the whole group in a single click. * One shared timeline: the full activity from every request inside the group, in chronological order, for clean handoffs and post-mortems. * No extra work for requesters: each person keeps a normal one-to-one conversation in Slack, Microsoft Teams, the portal, or email. ### Common use cases * **Incident management.** Slack goes down and 40 people report it within ten minutes. Group every "is Slack broken?" request, post one status update, and resolve them all together once the service is back. Each requester gets the all-clear in their own thread. * **Duplicate requests.** Three people in the Paris office submit the same "printer offline" ticket within an hour. Group them, answer once, and avoid three agents picking up three copies of the same problem. * **Onboarding or offboarding cohorts.** Five new hires start the same Monday and each one submits requests for laptop setup, app access, and badge issuance. Group the related requests by stage and run the same key actions across the cohort instead of jumping between fifteen tickets. * **Company-wide announcements that generate requests.** A tool migration, a security policy update, or a return-to-office change triggers a wave of related questions. Group them under one coordination thread, broadcast the official answer, and tag them for reporting. * **App rollout to a department.** A new design tool ships to the marketing team and twelve access requests arrive in the same hour. Group them, run a single approval thread with the app owner, and provision in one go. * **Recurring same-shape tickets.** Quarterly access reviews, monthly equipment swaps, or any wave of look-alike requests that benefit from a single coordinated pass rather than individual handling. ### How they show up in your inbox A Group Request appears in the list as a single stacked row with the `Group request` channel. The row aggregates its children: multiple requesters, the most recent activity time, and an unread state that lights up when any child is unread. * Stacked layout: one row per group, not one row per child. Children stop appearing on their own as long as they belong to a group. * Multi-requester display: the row shows every requester behind the group, not just one. * Live freshness: the group bubbles up the moment any child receives a reply, an action, or a workflow event. * Filter aware: any view that would match a child shows the group. Filter by priority, assignee, service, or tag and the group appears if any child matches.
### What you do from the group view The Group Request opens in a dedicated overlay built for coordinating across requests, not for a single conversation. You broadcast messages and run actions from one place and Siit fans them out to every child. * Bulk reply: send a public message and every requester sees it as a normal answer in their own channel. * Bulk internal note: capture investigation context across every child at once, agents only. * Key actions: change `Assignee`, `Priority`, or `Service` on the group and every child updates together. * Other bulk actions: `Resolve all`, change status, add or remove tags, snooze. Siit reports partial outcomes when a child cannot accept the action. * Message templates: the same templates you use on a single request work in the group composer. ### Operate on individual children Each child request keeps its own identity inside the group. Open any child from the group view, navigate between siblings, and unlink whenever a request no longer belongs. * Child overlay: open a child on top of the group to read the full request, see the sidebar, and run single-request actions. * Navigate between children: jump from one child to the next without leaving the group. * Unlink a child: removing a child stops the broadcast for that request and returns it to the list as a standalone. * Automatic cleanup: when the last child leaves, Siit deletes the empty group.
### Transparent to requesters Grouping is an admin construct. Each requester sees a standard request in their original channel, with their own private thread, their own status updates, and their own SLA. The fact that several requests share a group is invisible to them, so a broadcast reply reads exactly like a one-to-one answer. ### Where Group Requests fit Group Requests build on the primitives in [Request conversation](https://docs.siit.io/request-management/request-conversation) and reuse the same reply, note, approval, and template mechanics across many requests at once. The group surfaces in [Views](https://docs.siit.io/request-management/views) and respects the same filters and sharing rules. Group-level changes to assignee and priority follow the rules in [Assignment](https://docs.siit.io/request-management/assignment), and tag and SLA behavior on each child stays as documented in [Tags](https://docs.siit.io/request-management/tags) and [SLAs](https://docs.siit.io/service-catalog/slas). # Side panel The sidebar gives you instant context without leaving the request. See who’s asking, what they use, and what’s due—then take action in one click.
### What you’ll find at a glance * Request details: status, SLA clocks, team and assignee, priority, channel, and the associated service. * People: requester profile, manager, department, location, and a quick list of their recent requests. * Apps & devices: the systems and hardware tied to the requester or to the request itself, with quick actions for provisioning and troubleshooting. From here you can add participants, change priority, start an approval, or run a workflow. It’s the fastest way to understand who’s asking, what they need, and what to do next. ### Quick actions Common actions sit one click away at the top of a request . * In Apps: Provision, Revoke, Add to group, Open in Okta/Google/Azure AD. * In Devices: Assign, Lock, Wipe, Open in MDM. * Ticketing : Escalate ticket # Assignment Assignment in Siit happens in multiple places, in multiple ways. Some of it is manual — an admin picks up a request or reassigns it on the fly. Some of it is automatic — Siit distributes work based on inbox rules, workload, availability, and working hours. Most teams use a mix of both. ### Where assignment happens * **In the Service Catalog** — a default inbox or owner is set per service. Every request from that service lands there automatically. * **In Inbox settings** — the inbox distribution method, exclusions, and routing rules determine how requests spread across team members once they arrive. * **In Workflows** — requests can be routed to a specific inbox or person based on any condition: service, department, priority, form answers, requester location, and more. * **In the Request** — any admin can manually reassign the inbox or the assignee from the request sidebar at any time. All changes are logged on the timeline. ### Service-level defaults Use the Service Catalog to decide where requests should land by default. When an employee selects a service in Slack/Teams or the portal, Siit: 1. Creates the request with your pre-selected inbox or owner 2. Applies the service's SLA policy 3. Runs any related workflows
**Tips:** * Point repeatable services to a team inbox rather than an individual, then let the inbox method distribute the work. * For single-owner services (e.g. "Legal review"), assign to a specific person and add a fallback rule in workflows in case they're unavailable. ### Inbox distribution methods Once a request lands in an inbox, it gets distributed to a member using one of three methods: **Manual** (agents pick up work themselves), **Round-robin** (sequential rotation), or **Balanced** (goes to whoever has the fewest active requests). The method is set per inbox, so different teams can operate differently.
### Exclusions Specific admins can be excluded from automatic assignment while keeping full inbox access. Useful for managers who need visibility without a queue, or specialists who only handle escalations — they can still pick up or be assigned work directly.
**When to use this:** * A team lead or manager who needs inbox visibility but shouldn't carry a request queue * An admin on a temporary reduced schedule, is off or transitioning between teams * A specialist who handles only escalations, not first-touch requests ### Routing rules Three rules give finer control over how requests flow through an inbox automatically: * **Auto-assign to next available** — when no admin is currently available at the point a request lands, it waits and assigns automatically to the next one who frees up. * **Max open requests** — caps how many active requests any single admin can hold. New requests skip admins who have hit their limit. * **Auto-assign unassigned when capacity opens** — when an admin drops below their cap, the next unassigned request in the queue is automatically pulled to them, in a configurable priority order.
### Availability-based routing Admins can be assigned a Business Calendar within an inbox, defining their working hours in that context. Siit routes requests only to admins currently within their calendar's active hours. Because the calendar is set at the inbox level, the same admin can operate on different schedules in different inboxes.
**Example:** Your inbox has three admins — one in Paris (CET), one in New York (ET), one in Singapore (SGT), each with their respective Business Calendar assigned. A request arrives at 2pm CET: only the Paris admin is within working hours, so Siit routes to them automatically. ### Workflow-based routing and assignment For fine-grained control, use the **Assign to** action in a workflow. Combine it with conditions such as: * **Request data:** service, channel, tags, priority, status * **Requester attributes:** department, location, employment type, manager * **Form answers:** app selected, office, device type, urgency ### Manual assignment in a request From the request sidebar you can: * **Change Inbox** to move the request between teams. If the destination inbox uses Round-robin or Balanced, Siit auto-assigns to a teammate there. * **Change Assignee** to a specific person or click "Assign to me." * **Unassign** when you need the inbox method to pick the next owner. All changes are logged on the timeline for audit and reporting.
*** *Related:* [*Business Calendars*](/workspace/business-calendars) *·* [*SLAs*](/service-catalog/slas) *·* [*Workflows*](/core-plateform/images-and-media) *–* [*Actions library*](/workflow/actions-library) # Approvals Approvals can be preconfigured in a Service Catalog item or added ad‑hoc from any request. Choose sequential or parallel approvers, set due dates, and define what happens on non‑response. Approvers receive a clean card in Slack/Teams and can approve or decline with one click and an optional comment. Everything is recorded in the request timeline. If an approver is out, fallback logic routes to the manager’s manager, app owner, or a backup group. Changing scope—like a different app or higher access level—can automatically re‑request approval. Approvals can trigger downstream actions: on approval, provision access in Okta/Azure AD, add to a group, or notify the requester. On decline, update status and message the requester with next steps.
# Tags Tags are lightweight labels you add to requests to qualify work, drive automation, and report on themes. Create them on the fly from a conversation, or manage a curated list in Settings.
### What tags are good for * Triage: power Views and quick filters in the inbox. * Automation: trigger workflows when a tag is added (route, notify, change priority). * Reporting: slice dashboards by Tag name to spot trends and quantify effort. * Knowledge: standardize language across teams (e.g., “Okta,” “Payroll,” “Incident”). ### Where you use/manage tags * In a request: click Tags above the composer, search or create, then apply. * Settings → Tags: review usage, edit names/colors, and manage the catalog. #### Create and apply tags from a request * Click Tags → search existing or select New tag. * Pick a color and name that matches your taxonomy. * Apply multiple tags if needed; remove any tag with one click. * Changes are logged in the request timeline for audit. #### Automation with tags * Trigger workflows: Trigger = Tag is added → Conditions (optional: service, priority, channel) → Actions (assign, notify in Slack/Teams, set priority, add followers, set status, etc.). * Add/remove tags via workflows: use tags as both triggers and outcomes to build simple playbooks, e.g.: * New request in “Payroll” service → Add tag “Payroll” → Route to HR Payroll. * Tag “Incident” added outside office hours → Notify on‑call, set priority High. * SLA at risk → Add tag “SLA‑risk” to surface in triage views. #### See and report on tags * Inbox/list/board: filter by tag for fast triage. * Analytics → Request overview: add the Tag Name filter to measure volume, resolution time, and backlog by theme. * Exports and audits include tag data. #### Setup in minutes * Define 10–30 core tags you’ll use across teams (e.g., Apps: Okta, Slack; HR: Payroll, Time‑off; Ops: Provisioning, Incident). * Enable agents to create tags on the fly; periodically normalize in Settings → Tags. * Build 2–3 starter workflows using Tag is added. #### Tag activity is logged
Every tag you add to a request is recorded on the request timeline, so the full history of how a request was classified stays visible to the whole team. Each entry shows: * **Who** added the tag * **Which tag** was added * **When** it happened The event follows the same format as other request activity: `{Actor} added tag {tag name}`. > **Note** : This makes tagging traceable for audits and handovers: if a request was tagged as `Incident` or routed by a workflow, you can see exactly who applied that tag and when, without digging through the conversation thread. #### Best practices * Keep names short and unambiguous; use singular (e.g., “Incident,” not “Incidents”). * Prefer reusable category tags over one‑off labels. * Use color to group families (Apps one color, HR another). * Review monthly: merge/rename or remove low‑value tags; align with services. * Don’t overload: 1–3 tags per request is usually enough.
# Message templates Use message templates to write, personalize, and send answers to common questions while keeping your messages personal. Message templates let you save commonly used templates, snippets, and answers that you don't want our bot to send automatically. To create and manage Saved replies go to **Settings → Request settings → Message templates.** You can create a new one using the **+ New** button or edit existing ones by clicking on the list.
Customize each message template to fit your team or organization's needs. This ensures consistent, on-brand messages and saves admins time and effort, allowing them to focus on other important tasks.
### Personalize your message To make your message more personalized and engaging, you can incorporate variables like the recipient's name or office location. Adding articles or attachments can also make your message more informative and helpful. Personalizing your message and providing value can increase the chances of it resonating and achieving your desired outcomes.
### Using message templates Find and select a message template when sending replies, internal notes, or approvals directly from the message box.
# Public vs Private requests Some work benefits from visibility; other work demands confidentiality. Siit supports both modes so you can match the tone and sensitivity of each team. Public requests keep their conversation thread in the original Slack or Teams channel, which is perfect for an #it‑help channel where others can learn from the answer. Only the requester, participants, and authorized agents can act on the request, but the thread is discoverable in that channel for transparency. Private requests move the conversation to a direct message with the requester and the Siit App. Only the requester, explicitly added participants, and authorized agents can see the conversation. This is ideal for HR, Security, or anything sensitive that started in a public channel by mistake. Admins can set the default mode by channel, by catalog item, or by team, and agents can convert a request from public to private (or vice‑versa) when needed. Approvals are always presented privately to the approver, regardless of request mode. Reporting treats both modes the same, so your metrics stay comparable. Best pratrices Public requests are often the first place for internal support. Examples include: * `#ask-it` * `#help-people` * `#feedback-product` \ Private request: Feels personal, stays organized Private requests in Siit don’t go to an agent’s personal DMs.\ Instead, teammates message the Siit app. To the requester, it feels like a one-on-one conversation. For agents, it keeps personal inboxes clear and ensures all requests flow into the right workspace queue. *** ### [​](https://docs.ravenna.ai/guides/best_practices/public_vs_private_channels#%F0%9F%A7%A0-ravenna-supports-both)Siit supports both Siit gives you the advantages of each model without forcing your team to pick one. #### [​](https://docs.ravenna.ai/guides/best_practices/public_vs_private_channels#in-public-channels)In public channels * Turn any message into a request with a shortcut or emoji * Siit creates a thread and tracks it as a structured request * Multiple responders can collaborate without cluttering the channel * Requesters get automatic updates as progress is made #### [​](https://docs.ravenna.ai/guides/best_practices/public_vs_private_channels#in-private-dms)In private DMs * Requests can be submitted directly to the Siit App * Sensitive issues stay private but are still tracked in the workspace * Agents manage all requests from one Workspace, whether they start in a channel or a DM *** Siit adapts to how your team already works and makes support smoother across both public and private conversations. # Request shortcuts Manage your requests only using keyboard shortcuts
*** ## ⌨️ Keyboard Shortcuts Access your full list anytime with Ctrl + S Search & Quick Actions anytime with ⌘ + K ### 📋 List Navigation & Bulk Actions | Action | Shortcut | | --------------- | -------------------------------- | | Move up or down | ↑ / ↓ | | Open overlay | Enter or O | | Close overlay | Esc or C | | New | N | | Select line | X | *** ### 🧩 Request Property Editing | Action | Shortcut | | ---------------------- | ------------------------------ | | Status | S | | Assignee | U | | Inbox | I | | Associate to | A | | Followers | F | | Priority | P | | Tags | T | | Snooze | ⇧ + S | | Resolve | ⇧ + R | | Copy request ID | Ctrl + C | | Archive | ⇧ + A | | Group requests | W | | Add to a group request | ⇧ + W | *** ### ✏️ Writing Actions | Action | Shortcut | | ---------------------------- | ------------------------------- | | Send reply / note / approval | ⌘ + Enter | | Switch to reply | Ctrl + R | | Switch to note | Ctrl + N | | Switch to approval | Ctrl + A | | Mention admin | @ | | Find channel | # | | Message template | Ctrl + T | | Add article | Ctrl + K | | Upload attachment | Ctrl + U | ### 🧭 Navigation | Action | Shortcut | | ---------------------- | -------- | | Go to Request | G then R | | Next filtered view | ⌘ then J | | Previous filtered view | ⌘ then K | | Go to AI Agents | G then A | | Go to Workflow | G then W | | Go to Communication | G then C | | Go to People | G then P | | Go to Equipment | G then E | | Go to Applications | G then L | | Go to Knowledge | G then K | | Go to Dashboard | G then D | | Go to Export | G then X | | Go to Settings | G then S | # Service overview ### Create your first service 1. Go to Settings → Service catalog → Add. 2. Give the service a clear name and choose a category (you can manage categories from the same page). 3. Add a short, employee‑friendly description. This text appears in Slack/Teams cards and in the portal. 4. Choose a color and icon so it’s easy to spot at a glance. 5. Save. You now have a draft service with tabs for General, Request, Forms, Portal, Audience, and Analyze.
### Analytics for each service Every service has a focused dashboard so you can evaluate impact and improve: * Created vs resolved requests over time * Average first response and solving time * SLA attainment and trends * Volume by channel (Slack, Teams, Portal, Email) Use these insights to tune forms, adjust capacity, and demonstrate cost per request improvements.
#### Best practices * Organize services by category (IT, HR, Finance, Security, etc.) * Brand each service with a name, description, color, and icon for agents and the portal * Set default assignment rules to a team inbox or a specific owner * Apply SLA policies per service (first response and time to close) * Attach a service form so requesters provide the right details up front * Restrict availability with audience rules (by department, location, group, or custom attributes) * Analyze volume, SLAs, and outcomes for each service * Start with your top 10 services, then expand. Use Analytics to prune low‑value items. # Service forms Service forms let you ask the right questions up front. When an employee selects a service, Siit shows tailored fields to collect the details you need. Answers are submitted with the request and are visible to agents for faster triage, routing, and resolution.
#### What you can collect * Text: short answer, long answer * Numbers * Lists: single select or multi select (define your options) * Dates * Pickers from your internal data: person, application, team, department, office location, legal entity, country, equipment * **App access**: lets employees pick one or more apps to request. Choose which apps are eligible to show up in the picker (e.g. only Approved apps), and optionally require a Role, this hands the request straight to your App Access approval flow instead of creating a plain ticket. * File upload ### Where it appears * Slack/Teams request modal: the form expands after the employee chooses a service. * Portal: the same fields render on the service request page. * Request view for agents: answers are displayed at the top of the conversation so the team sees context immediately. {% embed url="" %} ### **Key behaviors** * Per‑service configuration: each service can have its own form. * Required vs optional: mark any field as Mandatory. * Order and format: choose field type, label, helper text, and drag to reorder. * Directory‑aware pickers: person/team/app/equipment fields draw from Siit’s unified data, so lists stay current. * Multi‑channel: the same form works in Slack/Teams and the web portal. ### What admins can expect * Immediate context: form answers are summarized in the request, reducing back‑and‑forth. * Search and triage: answers are visible in the request and can be referenced in workflows and views for routing and prioritization. Examples * IT access request: Application (picker), Access level (single select), Date needed (date), Manager (person), Justification (long text) * HR payroll question: Payroll period (date), Issue type (single select), Attachment (file) * Equipment request: Equipment type (single select), Model preference (short text), Office location (picker), Cost center (number) ### Best practices * Ask only for what’s needed to take action; keep mandatory fields minimal. * Use pickers (person/app/team/equipment) instead of free text to reduce ambiguity. * Put the most important fields first; add helper text for clarity. * Pair with workflows to auto‑route or set priority based on answers (e.g., Issue type = “Urgent payroll” → assign to HR‑Payroll and set priority High). # SLAs SLAs set clear expectations for how fast requests get responded to and resolved. Siit tracks two targets per request: **First Response Time** and **Resolution Time**. Both are visible to admins at all times, with color-coded status so nothing slips unnoticed. ### Per-priority rules SLA targets in Siit are defined by priority. P1 incidents can run against a 24/7 calendar with a 15-minute first response target. Standard requests can run against a Mon–Fri 9am–6pm schedule with a 4-hour target. Each priority level gets its own rule, its own calendar, and its own targets — independently. ### Calendar-aware timing SLA clocks only count down during active working hours. Time outside those hours — evenings, weekends, public holidays — doesn't count toward breach. Different teams can follow different schedules: your EU team's SLAs run on CET hours, your US team's on ET hours.
### Status at a glance Every open request carries a color-coded SLA badge: | Color | Meaning | | --------- | ---------------------------------- | | 🟡 Yellow | In progress — time remaining | | 🔴 Red | Breached — shows how long overdue | | 🟢 Green | Met — handled before the deadline | | ⚫ Grey | Missed but closed — shows how late | Status is visible in the request sidebar, list and board views, and the timeline. ### Breach alerts Workflows trigger notifications before or at breach — Slack message to the assignee, priority escalation, reassignment to an escalation queue. Teams catch SLA risk before it becomes a breach. *** *Related:* [*Business Calendars*](/workspace/business-calendars) *·* [*Assignment*](/request-management/assignment) *·* [*Workflows*](/request-management/assignment) *–* [*Actions library*](/workflow/actions-library) # Audience & visibility Advanced audience rules 🔒 Control who sees and can submit each service: * Target by department, location, employment type, group, or any synced attribute from your IdP * Expose sensitive services (HR, Security) only to the right audience * Make pilot services visible to a specific team before rolling out If a service is hidden from someone, they won’t see it in the portal or search results in Slack/Teams.
# Self service portal The Portal is your company’s self‑service home for internal resources. Employees can submit and track requests, find apps, browse the directory, and read knowledge—everything in one place. Admins brand and control access from Settings.
### Accessing the Portal * URL: yourcompany.siit.io * Sign‑in: Microsoft 365 or Google or SAML (same identity you configured in Siit) * Entry points: link from Slack/Teams, Web, or Admin console ### What employees see **My Requests** * Request history, Followed requests, Pending approvals, AI conversations (if enabled) * Search, filter by status, sort by date * Open a request to reply, attach files, or add participants **Services Catalog** * Browse categories (IT, HR, Finance, etc.) and open a service form to submit a request * Visibility honors service audience rules set by admins **App Library** * Find company tools by category, search, and mark favorites **Directory** * Search colleagues; see title, department, manager, and location **Knowledge Base** * Search and browse articles; open guides directly from results ### Create and manage a request
**+ Create** * Click Create a request (top right) or open a service from the Services Catalog * Fill the form, attach files, submit * Open a direct link to a specific service to land straight on that service's form, already selected and ready to fill, skipping the search-and-pick step > **Note** - Direct service links work the same way inside the Microsoft Teams embedded version of the portal. **Track and act** * My Requests shows status for open/closed items and those you follow * Reply to agents, add info, upload attachments * Approvals assigned to you appear under Pending approvals—Approve/Reject in one click ### AI in the Portal (Pro plan)
If enabled, employees can: * Ask questions in the search bar or AI conversations tab and get instant answers from your knowledge * Turn an AI exchange into a tracked request when human help is needed Admins control availability and guardrails in [Settings → Portal → AI](https://app.siit.io/settings/channel/portal) ### Admin setup
1. **Settings → Portal** * Settings: Portal name, domain, logo, and cover image; Set live when ready * Navigation: show/hide and reorder My Requests, Services, App Library, Directory, Knowledge * AI: toggle AI assistant and configure sources/permissions * Survey: enable CSAT after resolution * Audience: choose who can access the Portal (all employees or specific groups)
2. **Publish content** * Services: configure forms, routing, SLAs, and audience; mark visible in Portal * Knowledge: create categories and articles; set visibility * App Library: organize apps by category and ownership #### What to expect * A single, branded destination for help * Fewer back‑and‑forths thanks to service forms and knowledge suggestions * Consistent tracking: requests created in the Portal sync with Slack/Teams conversations and the Siit inbox #### Best practices * [ ] Pin the Portal link, or a direct link to a specific service, in Slack/Teams and your intranet * [ ] Feature 6–10 most requested services on the Services page * [ ] Keep forms short; ask only what’s needed to start * [ ] Use Knowledge for common “how‑to” and policy questions; refresh monthly * [ ] Enable AI when your knowledge base is ready to deflect simple requests # AI trust model Siit’s AI is designed to be useful and governable. Our trust model gives admins fine‑grained control over what AI can read, propose, and execute—backed by least‑privilege permissions, approvals, and full audit trails. It applies to both agents:
/pages/4oVJ6LnPZPXbfnCNLi9AKnowledge answers, triage & request deflection./pages/4oVJ6LnPZPXbfnCNLi9A
/pages/OlryuObeb41k838DG7O3Executes operational tasks across your tools (for example, Okta, Jamf) via curated playbooks./pages/OlryuObeb41k838DG7O3
### What “trust model” means in Siit * Identity and scope * AI acts as a workspace agent with role‑based permissions. It only sees data the requester is allowed to see (service audience, article visibility, directory rules). * For third‑party systems, the IT Agent uses dedicated, scoped service accounts or OAuth scopes—never broad admin tokens by default. * Knowledge boundaries * You choose the knowledge sources (Siit Knowledge, specific collections, selected URLs/docs). * Answers cite sources. If no trustworthy source exists, the agent defaults to “I don’t know” and can open/route a request. * Action governance * All actions are packaged as playbooks (for example, “Reset Okta MFA,” “Add to App X group”). * Per‑playbook autonomy levels: * Suggest only: propose steps to an agent. * Execute with approval: require human approval (assignee, team lead, manager). * Auto‑execute: run automatically when conditions are met. * Extra controls: allow/deny lists, parameter whitelists, requester eligibility checks (employment status, manager, location, device posture). * Human in the loop * Any interaction can be escalated to a human. Approvals are private and auditable. Agents can always override or roll back via a paired playbook. * Observability and audit * Every answer, decision, and external action is logged in the request timeline with who/what/when, inputs, outputs, and the playbook used. * Shadow mode: test playbooks with “simulate” to log what would have happened without making changes. * Safety and privacy * Least‑privilege connectors, token rotation, and encryption in transit/at rest. * Prompt hardening: sensitive tokens never included in prompts; PII redaction rules for inputs you choose. * Rate limits and throttling per user/channel to prevent abuse. * We use model providers through “no training” endpoints when available and do not permit providers to use your content for their own model training. Refer to your chosen provider’s data‑handling terms. ### How each agent applies the model [Triage Agent](/ai/triage-agent) * Reads only the knowledge sources you enable; respects article visibility. * Produces short answers with citations; can suggest forms or open a request when needed. * Optional behaviors: auto‑tag, classify to a service, language detection and response in the user’s language.
[IT Agent](/ai/it-agent) * Executes only the playbooks you publish and only for eligible users. * Typical uses: unlock Okta account, reset MFA, add to group, provision/deprovision app, run Jamf remediation. * Guardrails: require approvals for high‑impact operations, restrict to office hours, or limit to P1 incidents. ### Admin controls * Sources and tone * Choose knowledge collections; set answer length and personality. * Playbooks and connectors * Connect apps with scoped credentials (Okta, Azure/Google, Jamf, etc.). * Build playbooks with pre‑checked conditions, required parameters, and post‑actions (notify, tag, update status). * Set autonomy: Suggest, Execute with approval, or Auto‑execute. * Policies * Who can invoke which agent and where (channels, DMs, Portal). * Office‑hours rules and rate limits. * Data filters and redaction preferences. * Kill switch * Pause an agent or a single playbook instantly; all requests fall back to human. ### Rollout checklist * Start in a pilot channel with Shadow mode for IT Agent playbooks. * Enable AI Assist on a small, high‑quality knowledge collection; review answer sources. * Add approvals to any playbook that changes identity or device state. * Monitor logs and CSAT; gradually increase autonomy where safe. ### Model providers and data residency Which LLMs we use * Providers: OpenAI and Mistral AI. Both are supported across our agents (AI Assist and IT Agent). * Why two: this lets us meet performance, locality, and compliance requirements per customer. How we choose a provider for you * Workspace default: set a default provider in Settings → Agents. * Per‑agent override: select a different provider for AI Assist or IT Agent if needed. * Regional preference: we adapt to your company’s location and data‑residency policy: * EU residency: route via **Mistral AI** (EU‑hosted) by default. * US/global: route via **OpenAI.** * We can switch providers on request without changing your workflows or playbooks.
# Triage Agent The Triage Agent handles request intake conversationally. It sits in your Slack and Teams channels and in the employee Portal, understands what an employee needs, deflects with a knowledge article when one exists, and otherwise creates a complete, structured request: right service, form fields filled, priority set, tags applied. {% embed url="" %} ### What you get * **Knowledge deflection that reads the conversation.** The agent checks your knowledge base first and suggests the relevant article with a summary. Employees accept or decline in plain language, no exact phrasing or button clicks required. If the article resolves the problem, no request is created. * **Intelligent service matching.** The agent reads your Service Catalog to route each request to the right service. * **Complete form compliance.** Every required field, including custom and multi-select fields, is collected through conversation and validated against your form's constraints before the request is created. * **Priority and tags, set automatically.** Derived from the conversation content and your service configuration. * **Request on behalf.** Managers can open requests for their direct reports. The agent identifies the requester, confirms, and adds the manager as a follower. * **Full conversation on the timeline.** The entire AI exchange is attached to the request, so admins have complete context without opening Slack. * **Works where employees already are.** Slack, Microsoft Teams, and the employee Portal. ### Setup * **Channels:** which Slack or Teams channels the agent listens to. * **Knowledge behavior:** whether the agent checks the knowledge base before moving to intake. * **Request behavior:** **Try to create directly** skips the confirmation step; **Always show pre-filled form** lets the employee review and submit. * **Stale reminders:** how long the agent waits before nudging an abandoned conversation. For step-by-step setup, see the [Triage Agent guide](https://help.siit.io/triage-agent-guide) in the Help Center. ### Best practices * Start with one channel. Run real requests through it, then expand once matching looks right. * Write service `About` fields in plain language, listing the request types each service covers. This is the single highest-leverage change for accuracy. * Keep forms to 3 to 6 distinct, clearly labelled fields. Multi-select options should describe distinct scenarios, not synonyms. * Keep your knowledge base current. The agent surfaces what you publish, stale articles included. * Begin with **Always show pre-filled form** if you want employees to confirm before a request is created, then move to direct creation once you trust the matching. #### Availability The Triage Agent is part of the **Pro plan**, with a 14-day free trial available on any plan. AI provider selection, permissions, and audit behaviour are covered in the [AI trust model](https://docs.siit.io/ai/ai-trust-model). # Assist Assist is the assistant built into your Siit admin dashboard. Ask it a question about Siit and it answers from the documentation. Ask it to do the work and it builds the configuration for you #### ► Assist can only see and do what you can This is the whole design. Assist runs on your behalf, with your role and your permissions. It cannot read a request, a person, or an inbox you cannot already open in the dashboard, and it cannot perform a write you could not perform yourself in the UI. Scoping is identical to the Siit MCP. On top of that, every action that changes your workspace pauses and asks you first. You approve or reject it in the conversation before anything is written. #### What you can do Assist opens on three starting points, each with ready-made prompts. | | What it does | Ask it | | -------------------- | ----------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Build my setup** | Creates and edits your configuration: services, service forms, workflows, inboxes, knowledge articles | "Suggest three workflows I should set up based on my requests." / "Create a service catalog based on past requests." / "Create an onboarding workflow." | | **Ask the docs** | Answers product and setup questions from Siit's public documentation, Help Center, and API reference | "Where do I set up my app access policies?" / "How do I set up SSO?" / "How do SLA rules handle business hours?" | | **Analyze requests** | Reads your live request data and turns it into answers, summaries, and drafts | "How many requests last week, by service?" / "Find open requests older than 7 days with no assignee." / "Write my inbox weekly update from last week's requests." | Assist reaches your workspace through the same toolset as the Siit MCP, so anything the MCP can read or write, Assist can too: requests, people, apps and equipment, services, workflows, app access roles, knowledge base articles, and your organization structure. See MCP for the full tool list. #### How it works 1. Open **Assist** from the top bar of the admin dashboard. It opens in a side panel and the page behind it stays usable. 2. Ask in plain language, or pick one of the suggested prompts. 3. Assist works out loud. You see each step as it reads your workspace, checks the documentation, and prepares changes. 4. Before any write, Assist stops and asks for approval. The conversation stays paused until you approve or reject. 5. Stop a run at any point with the stop button. Nothing already approved is rolled back. 6. Conversations are saved. Reopen a past one from the history icon to pick up where you left off. #### Where its answers come from Assist has two sources, and it separates them: * **Your workspace**, for anything about your own requests, people, and configuration. * **Siit's public knowledge**, for anything about how the product works: [docs.siit.io](https://docs.siit.io), [help.siit.io](https://help.siit.io), and the API reference at [developer.siit.io](https://developer.siit.io). Nothing from your workspace is sent to the documentation, and nothing from the documentation is treated as configuration. #### Attachments Drop a file or a screenshot into the conversation and Assist reads it. The common case is migration: paste a screenshot of your current setup in another tool and ask Assist to build the equivalent in Siit. #### Common workflows * **Trial day one** : "Create a service catalog based on my past requests" turns an empty workspace into a working catalog in one prompt. * **Migration** : screenshot your existing intake form from your old tool and have Assist rebuild it as a Siit service with the same fields. * **Find the automation gap** : "Which services get the most requests but no automation?" then have Assist draft the workflow it just recommended. * **Weekly reporting** : "Write my inbox weekly update from last week's requests." * **Setup questions without a support ticket** : "How do SLA rules handle business hours?" answered from the docs, in context, in the product. #### Tips * One task per conversation. Assist replays the full thread on every turn, so a long conversation that has drifted across three topics is slower and less accurate than a fresh one. * Say which object you mean. "Update the Onboarding workflow" beats "update the workflow." * Read the approval prompt before approving. It names the exact action and its parameters. * When Assist is wrong about the product, it is usually because the documentation is wrong. That is worth reporting. #### Availability Assist is **available on every plan**, with a fair use policy applied per account. There is no AI add-on and no per-seat AI upgrade. If you hit your fair use limit, contact your Account Manager and they will move you to the right plan. > **Coming soon.** Custom playbooks and instructions per workspace, and connecting external MCP servers so Assist can act in your other tools. # IT Agent Siit’s AI‑powered IT Support Agent — an intelligent teammate that can autonomously run playbooks, take approved actions in your tools, and escalate to humans when needed. {% embed url="" %} ### What it can do * Proactive resolution: watch for issues and fix them before they spread (e.g., MFA lockout resets with approval). * Automated actions: run your IT playbooks across tools without manual steps. * Personalized support: understands your org (people, apps, devices) to tailor responses and actions. * Effortless approvals: collects approvals from the right approvers in Slack/Teams and proceeds instantly when granted.
### Glossary * **Agent**: an entity that uses LLMs to follow playbooks, decide next steps, and act. * **Action**: an operation the agent can execute (Siit‑native, integration, or custom webhook). * **Playbook**: a user‑defined procedure written in natural language that tells the agent what to do and when. ### Creating a Playbook How it works You define a playbook in plain language. The agent follows it step‑by‑step, asking for missing information, running actions, and respecting your approval rules.
1. **Condition (the trigger) Describe when the playbook should start.** * Example: “When an employee asks for new equipment.” * You can scope by channel, tag, or service to target where it runs. 2. **Instructions Write the steps the agent should follow. Insert actions inline using /.** * Example structure: * Step 1: Understand the reason for the request * Step 2: Determine hardware requirements * Step 3: /create request for hardware * Step 4: /send slack message to employee and their manager with the Request ID
3. **Available actions Use actions inside your steps to let the agent do real work.** **Core Siit** * /create request * /submit request button * /suggest article * /send email * /send slack message via Siit app * /send teams message via Siit app **Okta** * /okta reset multi‑factor (Approval available) * /okta reset password (Approval available) * /okta add to group (Approval available) * /okta add applications (Approval available) **JumpCloud** * /jumpcloud add to group * /jumpcloud reset user password * /jumpcloud reset user mfa **Google** * /google add to group * /google remove from group **Slack** * /slack add user to channel * /slack make channel private/public * /slack send message to channel * /slack archive **Ticketing and webhooks** * /zendesk create ticket (Approval available) * /jira create issue (Approval available) * /webhook (Approval available) **Custom actions Extend the agent with your own webhooks.** * Name and description: make intent clear. * URL: the endpoint to call. * HTTP method: POST recommended for sending data. * Headers/body: add headers or use raw JSON; insert variables from the playbook context (requester, app, device, etc.). **Approvals Gate sensitive steps with approvals.** * Choose approver: Manager (resolved dynamically), or Specific employees. * Condition: First to approve or All users must approve. * Running mode per action: Auto‑run or Approval required. The agent requests approval in Slack/Teams and continues as soon as it’s granted. 1. Mentions @mention people, teams, or inboxes to keep the right stakeholders informed or to escalate. 2. Articles Attach relevant knowledge to the playbook so the agent can include accurate instructions in replies. **Governance and safety** * Audience: restrict where the agent listens and acts (channels, teams, services). * Sandboxed actions: only whitelisted actions are available to the agent. * Approvals: mandatory for third‑party changes unless explicitly set to auto‑run. * Audit: every step (prompt, decision, action, approval) is logged; you can replay runs. * Gradual rollout: publish playbooks as Draft → Pilot audience → Live. Use “simulate” mode to validate before allowing actions. **Great use cases** * Access requests: approval → Okta add to group → notify requester. * Google Group provisioning: approval → Google add to group → notify requester. * MFA/Password resets with manager approval. * New laptop requests: collect specs → create request → inform manager → tag and route. * Slack hygiene (coming soon): archive channels with approvals; manage membership. ### Attachment understanding The Triage Agent can now read the files an employee shares during intake not just their text. When someone attaches a screenshot, image, document or spreadsheet while describing a problem, the agent reads and analyses its contents and uses them as extra context to triage the request. **What this unlocks** * **Better service matching.** A screenshot of an error screen or an app helps the agent route to the right service, even when the written message is vague. * **Fuller requests.** Details visible in the attachment (error messages, device info, order numbers) can be used to pre-fill form fields and the description. * **Fewer back-and-forths.** The employee doesn’t have to re-type what’s already visible in the image or document they shared. **Example** An employee posts “this keeps happening” with a screenshot of a VPN error. The Triage Agent reads the error in the image, matches the request to the *Network / VPN access* service, and pre-fills the description with the error text all before an admin sees the request. Attachment understanding works within the same conversational intake flow, on top of everything the agent already reads (knowledge base, services, form fields, and user data).
### Rollout checklist ✅ * Start with [Triage Agent ](/ai/triage-agent) * Define 2–3 high‑confidence IT playbooks (password reset, app access, laptop request). * Require approvals on any action that changes identity, security, or data. * Limit agent scope to a few channels and services; expand once KPIs look good. * Track tags like “AI‑assisted” and dashboards to quantify time saved. # Triggers overview ### Triggers: when an automation begins Each workflow starts with a trigger. Siit provides three trigger families so you can react to work, people, and time. **Request triggers** * Examples: Request submitted, Request resolved, Requester message received, Admin message sent, Tag added, Request marked In progress/Waiting/Snoozed/Reopened, Snooze expired, SLA breached, Requester unresponsive. * Use these to drive intake routing, approvals, escalations, and auto‑close flows. **People triggers** * Examples: Start date, End date, Work anniversary, Birthday, Probation period. * Use these for onboarding/off boarding sequences and recurring employee touch points. **Date triggers** * Example: Specific date. * Use for scheduled communication, reminders, or periodic maintenance. ### Conditions: target precisely Refine when a workflow should run using rich conditions. You can mix request data, requester attributes, and form answers. * Request context: status, priority, channel, inbox, assignee, tags, service (“Associated to”), created/updated dates, SLA state, satisfaction rating. * Requester attributes: department, manager, job title/level, location, employment type, and any IdP‑synced custom attributes. * Form results: any field from the service form (e.g., target app = “Okta,” office = “Paris”). * Combinators: AND/OR groups, equals/contains/one of, greater/less than for numbers and dates. # Request triggers Request triggers start an automation when something happens on a request. Use them for intake routing, approvals, escalations, and auto‑close flows. They’re the fastest way to remove manual steps from day‑to‑day support. ### Available triggers * Request submitted: Fires when a new request is created (from Slack/Teams, portal, email, or API). * Request resolved: Fires when a request is marked Resolved. * Requester message is received: Fires when the requester replies. * Admin message is sent: Fires when an agent replies publicly. * Tag is added: Fires when a specific tag is applied. * Request marked as In progress: Status change to In progress. * Request marked as Waiting: Status change to Waiting (often used to pause SLAs). * Request snoozed: A snooze is set. * Request snooze expired: A snooze ends. * Request reopened: Status returns to Open from Resolved/Closed. * SLA breached: A first reply or resolution target has passed. * Requester unresponsive: Requester hasn’t replied within your threshold. ### When to use * Intake and triage: auto‑assign, set priority, tag, and send acknowledgements when a request is submitted. * Approvals and provisioning: start manager/app‑owner approval and, on approval, provision access. * SLA guardrails: escalate before/after breach; notify team leads; raise priority. * No‑response and housekeeping: remind, auto‑close, or reopen with the right status and notes. * Major incidents: when a tag is added (“incident”), create a swarm channel and open tracker issues. ### Conditions you can add * Request fields: service (Associated to), status, priority, inbox, assignee, channel, tags, created/updated dates, SLA state.... * Requester attributes: department, location, manager, contract type, job title/level, legal entity... * Service form answers: any field you added to the service form (e.g., target app, office). ### Common workflows * Auto‑triage and route * Trigger: Request submitted * Conditions: Associated to = “App access”, Department = Sales * Actions: Assign to IT Ops inbox, set priority = Low, send acknowledgement template * Approval → provision → notify * Trigger: Request submitted * Actions: Start manager approval → Path 1 (Approved): Okta “Add application to user”, DM requester. Path 2 (Declined): set status Waiting, send decline message * Escalate on SLA risk * Trigger: SLA breached * Actions: Increase priority, post to #it‑ops, assign to team lead * Auto‑close no response * Trigger: Requester unresponsive * Actions: Send reminder; after n days set status Resolved with resolution note ### Best practices * Name clearly: “IT — App access — Request submitted.” * One workflow per use case per trigger. Avoid collisions; use conditions for specialization. * Add a tag (“auto‑provisioned”) for reporting impact. * Keep steps readable. Use Paths for exceptions only. # People triggers People triggers start automations from employee lifecycle dates. They’re ideal for orchestrating onboarding/off boarding and scheduled employee touch points without opening a request first. Available triggers * Start date * End date * Work anniversary * Birthday * Probation period ### When to use * Onboarding: coordinate tasks across IT, HR, Facilities on the employee’s start date. * Off boarding: revoke access, collect equipment, and notify stakeholders on end date. * Check‑ins: probation reminders to manager and HR. * Recognition: send automated anniversary or birthday messages.
### Conditions you can add * People attributes: department, location, manager, employment type (employee/contractor), legal entity, job title/level. * Groups: teams and custom groups you defined. * App/device context: whether the person owns certain apps or equipment. ### Common workflows * Day‑1 onboarding * Trigger: Start date * Conditions: Department = Engineering, Location = London * Actions: Okta or google “Add to groups,” create Jira/Linear tasks, send welcome kit email, notify hiring manager * Off boarding * Trigger: End date * Conditions: Employment type = Employee * Actions: Revoke sessions, Google group removal, remove app access, create pickup request for equipment, DM manager with completion summary * Probation review * Trigger: Probation period * Conditions: Department = Sales * Actions: Send checklist to manager, open a request if feedback is missing after 3 days * Celebrations * Trigger: Work anniversary * Actions: Post a message in #all‑hands and DM the manager with a recognition template ### Best practices * Keep sensitive steps (de-provision, wipe) behind approvals for contractors if needed. * Use categories (HR, Security) and roles to restrict who can edit these flows. * Add “owner” chips to actions that hit external systems for clear accountability. # Date triggers Date triggers run on a specific calendar date. Use them for scheduled communications, maintenance reminders, audits, and periodic housekeeping—no request or person event required. ### Available trigger * Specific date ### When to use * Monthly or quarterly reviews: send reminders or open tracker tickets on a set date. * Hardware maintenance: nudge owners to update OS or schedule checks. * Reporting and digests: send a summary of volume, SLA, and cost per request to leaders. ### Conditions you can add * Scope by object data so the run is targeted: * People: department, location, legal entity, employment type... ### Common recipes * Monthly updates * Trigger: Specific date (1st of month) * Leadership digest * Trigger: Specific date (weekly) * Actions: Email execs a summary of created/resolved, SLA attainment, automation savings ### Best practices * Use tags like “scheduled-run” to track and report the impact of date‑based automations. * Bundle communications: prefer one digest per audience over many single pings. * Keep destructive actions (deprovision, resolve) behind conditions that are easy to audit. # Actions library ### Actions: what workflows can do Mix native request actions, notifications, webhooks, and third‑party integrations. Here’s the menu you’ll use most. **Request** * Set request status * Set priority * Assign to (team inbox or individual) * Associate to service * Start approval(s) * Send quick reply (use a message template) * Add a note (internal) * Add/remove tags * Add followers * Set resolution and close * Snooze / Pause or resume SLA **Communication** * Send a communication (email or portal notification) * Post a message in a Slack channel (for swarms, incidents) * DM requester or assignee via Slack/Teams **Paths** * Paths for conditional branches **Webhook** * Call external webhook with request payload **Third-party applications** * Identity and access (Okta, Azure AD, Google Workspace—varies by connection) * Activate/suspend user * Reset password * Add/remove from application * Add/remove from group * Revoke/restore sessions * De-provision user * Issue trackers * Jira: create issue; sync status/links * Jira Service Management: create linked ticket * Linear: create issue; sync status/links * More integrations * Add additional tools as you connect them; actions appear automatically in the list. # Branching & approvals ### Workflow Branches Branches let a single workflow split into different paths based on conditions about the request, the requester, time, or context. Use them to build multiple scenarios in one workflow (for example, handle HR vs. IT, US vs. EU, inside vs. outside office hours) without duplicating workflows. #### What to expect * One trigger, many outcomes: evaluate conditions and run different action sequences under each branch. * Independent evaluation: each branch runs only if its condition is true. Multiple branches can run if several conditions match; make conditions mutually exclusive if you want only one path to fire. * Mid‑flow decisions: insert a Branch anywhere in your action list to fork later steps based on updated fields or tags set earlier in the same workflow. * Full audit: which branch(es) ran is logged in the request timeline. #### What you can branch on * Request fields: service, status, priority, inbox, tags, channel, source, SLA state, snooze/waiting, etc. * Requester attributes: department, team, location, manager, contract type, seniority, employment status. * Time and context: Office hours (within/outside), created date/time, day of week. * Custom signals: your own tags or fields added earlier in the flow, or responses from webhooks. #### Typical use cases * Language routing: if language = fr → reply with French template; if = en → English template. * Access requests: if service = App Access and office = Madrid → set approver = local manager; else → app owner. * After‑hours handling: if outside office hours and priority < P1 → auto‑reply and queue; if outside hours and P1 → notify on‑call. * Region/team triage: if requester.department = Sales (EMEA) → HR‑EMEA inbox; if = Sales (AMER) → HR‑AMER inbox. * Risk paths: if tag = “incident” → set priority High, add security followers; if tag = “FAQ” → auto‑reply and close when acknowledged. *** ## Approval requests #### What is an approval request, and why is it important? In a corporate environment, certain actions — such as accessing an app, ordering new hardware, or requesting time off — often require **prior validation**. This validation ensures that the right people are aware of the request, confirm its legitimacy, and approve it before resources are allocated or changes are made. Approvals help businesses: * Maintain control over costs and security * Ensure alignment with internal policies * Improve accountability across teams Siit includes a powerful and flexible **Approval Request** feature that fits seamlessly into your automated workflows. Whether it’s granting app access, ordering equipment, or processing a specific employee request, Siit enables you to trigger **automated approvals** to the right people — at the right time. #### How to set up an approval in your workflow? The **Approval** is an action that can be added to any requests workflow via the "Select approver" action. {% stepper %} {% step %} ### Add an Approval action Add an **Approval** action at the point where validation is needed. ![](/files/e495b31b16697b35da816a3c24ccb939f2b83bd6) Once added, it will automatically present the two branches for the "approved" or the "rejected" option, allowing you to configure follow-up actions according to the choice made. ![](/files/ba0967e5743aff7a21d49a368c338487466e5dea) You can set up **single** or **multi-level** approval sequences. {% endstep %} {% step %} ### Define the approver * Use dynamic fields like “Manager” or “App Owner” to automatically pull the right person from your data. * Or assign a fixed employee as approver. * Pick a team or an inbox instead of a named person. Everyone in the group is notified, and the first to respond decides for the group.
{% endstep %} {% step %} ### Set up reminders Set up **reminders** to ensure follow-up if no action is taken. If the approval is not given after a certain time (from 1 day to several weeks), you can configure automatic reminders directly from the approval configuration to prevent the rest of the flow from proceeding. ![](/files/b387a60c2542ea3bb875918eb9f1824d2ac67c73) {% endstep %} {% endstepper %} #### How to approve? Approvers are notified on Slack or Teams, then land directly on the request to decide. The **Approve** and **Reject** actions sit inline on the approver's own row — no separate approval screen to find. * If the admin added a message for approvers, it shows above the actions, so the approver has the context before deciding. * On a request with several approval rounds, each pending approver sees their own **Approve** / **Reject** next to their name, so there's no hunting for which decision is yours. * The same experience is available in the Self-Service Portal. ![](/files/3030e620672f9d7cb006d9f451840b8a2f58d3cb)
# Dashboards Requests metrics allow you to monitor your employee support performance. ### Request Dashboard We’ve improved the existing dashboard to display weekly request metrics, providing insights to analyze the volume of requests you’ve been managing. It also includes reports on the satisfaction of employee support. New filters: you can now filter data by “Submitted from” and “Channel” for more granular insights. #### AI agents overview Monitor how your AI Agents are performing: conversation volume, deflection rate, request creation, and actions taken, available in weekly or monthly views. * **Pre-request overview :** total conversations, article suggestion rate, deflection rate (questions your agents resolved without reaching an admin), and escalation rate. * **By AI Agent :** conversations, article suggestion rate, and deflection rate over time, broken down per agent, plus escalated conversations and escalation rate per agent. * **By service :** average user messages before a request is created, and how many of those conversations end up escalated. Filter by date, Agent, Service, Inbox, Channel, or Article suggested category.
{% hint style="info" %} Available on the Pro plan. {% endhint %} ### SLA Dashboard This dashboard focuses on the SLA feature (currently in beta) and helps you keep track of team performance. For the two targets, “First Time Response” and “Time to Resolve,” you will be able to evaluate your achievement rate.
Available filters: * Date * Priority * Requested by * Channel * Assigned to Inbox * Assigned to * Associated to * Tags * Requester Location * Requester Department * Requester Team ## Evolution of requests * Repartition by status — Repartition of requests per status (“New”, “In progress”, “Waiting”, “Resolved”). * Requests over time — Evolution of new and resolved requests during the last 12 months. ## Performance and SLA * Avg. Solving time (days) — Average of total requests solving time (time when status is “Resolved” - time of creation). * Avg. Solving time over time (days) — Evolution of average solving time during the last 12 months. * Completed requests per admin — List of Siit admins with their total of solved requests and their average solving time. * Distribution by Day of the week — Repartition of requests per day of the week (based on “creation date”). * Distribution by Hour of the day — Repartition of requests per hour of the day (based on “creation time”). ## Associated applications / services * Top associated applications / services — Repartition of requests per application / service (including a repartition per status). * Details \[List] — List of applications / services associated to the requests (“name”, “type”, “requests number”, “avg. solving time (h)”, “last request date”). # Export Export lets you pull structured data out of Siit whenever you need to analyze it elsewhere or share a snapshot with stakeholders. You can export any core object, filter to exactly the rows you need, and the data you see is governed by your role and field visibility. #### What you can export * Requests: full request table with requester context, status, priority, SLA dates, tags, channel, inbox, assignee, service/category, rating, and more. * Communication: outbound messages and satisfaction surveys. * People: directory data and groups (department, team, office, legal entity). * Services: catalog items and configuration metadata. * Applications: app inventory and ownership fields. * Equipment: device inventory, lifecycle, ownership, and key attributes. * Workflows: titles, state (Live/Paused/Draft), trigger, category, and usage counts. Suggested visual * \[Screenshot] Export page with tabs (Requests, Communication, People, Services, Applications, Equipment, Workflows) #### Filters Filters use the chip-based filter bar to narrow your export. Filters vary by object and typically include: * Requests: Requester, Requester team/department/office, Associated to (service), Service category, Channel and Channel details, Status, Priority, Inbox, Assignee, Created at, First replied at, Completed at, Rating, Tags, Approval pending, Archived. * People: Department, Team, Office location, Legal entity, Employment type, Lifecycle. * Applications: Category, Owner, Lifecycle, Sensitive data. * Equipment: Type, Lifecycle, Owner, Office location, Last contact date. 💡 Tip * Apply date filters first (Created at, Completed at) to keep exports focused and fast. #### Permissions and scope * Role-based access: Only users with the Export permission can access the Export area. Admins can restrict which objects are exportable per role. * Field visibility: Sensitive fields (for example, compensation or PII) respect field visibility settings. If a field is off for your role, it won’t appear in the preview or file. * Data scope: Exports respect object-level permissions. You can only export what you can view in Siit. # People **People** are the central object in Siit. They represent every individual your organization interacts with employees, new hires, alumni, and external partners. Each person connects seamlessly to their apps, equipment, and requests, creating a unified view of the employee experience. **Why it matters** * Faster intake: pre‑fill forms and enrich requests with role, manager, department, and location. * Smarter routing: assign to teams based on requester attributes (e.g., “Route Finance to Finance Ops”). * Targeted approvals: automatically select a manager or app owner. * Reporting: slice metrics by department, office, legal entity, or employment type. **Groups and org structure- create & manage:** * Teams * Departments * Office locations * Legal entities Use these groups to power audience rules in the Service Catalog, conditions in Workflows, and filters in Reporting. **Fields and source of truth** * Define the People fields your organization uses (e.g., Department, Job title, Manager, Contract type, Cost center). For each field: * Pick a priority source (e.g., HRIS or IdP). If multiple systems provide the field, the priority source wins. * Control visibility (on/off) for privacy and least‑privilege access. * Add your own custom fields when needed. **People list and profiles** * List: browse and filter your directory by group, lifecycle, location, or any field. Save common filters as views. * Profile: open a person to see: * Overview (role, manager, groups) * Activity timeline (recent requests) * Active apps (and ownership) * Equipment assigned * Documents (optional) From a profile, you can start a new request, message the person, or jump to related objects. **Managing the primary email** When a person has several email addresses synced from your integrations (an HRIS email change, or an IdP with an active and a suspended profile), Siit holds one as the primary. That's the address integration actions resolve against. * Admins with user-management permission can change the primary email directly from a person's `...` actions menu, without contacting support. * Integration lookups (JumpCloud, Okta, and others) resolve against the new primary right away. * Each change is recorded as a timeline event on the person, naming the new address and the one it replaced. > **Note** : This action is only available when a person has more than one known email address. # Apps Applications are your app inventory: every tool employees use, along with ownership, lifecycle, costs, and security attributes. **Why it matters** * Clear ownership: know who approves access and who to notify during incidents. * Better workflows: route requests by app, pick approvers automatically, and trigger provisioning in tools like Okta/Azure AD/Google Workspace. * Visibility: analyze usage, categories, and costs. Manage application fields Customize the fields that describe apps (and their visibility). Common fields include: * Owner, Teams, Category, Lifecycle (e.g., Active, Security review) * Sensitive data (Y/N), Status page URL * Contract details (renewal date, vendor, currency) * Annual cost, Licenses, Jurisdiction, Hosting Turn fields on/off and set the structure that fits your governance. **Inventory and profiles** * List: search and filter apps by category, owner, lifecycle, or cost. * Profile: see the app’s details, owners, related teams, and linked requests. From here, open the status page or start/approve access workflows. **Active Users** Every app profile has an **Active Users** tab: a live, reconciled view of everyone who currently has access, pulled together from every source Siit knows about. * **Always up to date** : a grant or revocation through your IdP or through App Access updates the list immediately. Siit reference-counts access, so someone stays listed as long as any source still grants it, and drops off only once the last one is gone. * **Origin at a glance** : each person shows how they got access: an IdP provider, App Access, or a direct admin add. Access can come from more than one source at once. * **Full activity history** : an activity timeline follows every event behind the current state: request creation, approvals, manual and automatic actions, provisioning failures, cancellations, and planned deprovisioning.
# App access policies {% hint style="info" %} App Access Policies are available on the Pro plan. {% endhint %} App Access Policies are how Siit governs access to your apps end to end: who can ask, what they have to provide, who signs off, and how the access actually lands in the target system. Every workspace and every app start with safe defaults so the feature works on day one, then earns its keep as you configure Roles per app.
### Why App Access Policies matter * **Central governance**: define an approval cycle once and reuse it across every app, instead of recreating the same `Manager + App owner` chain in 30 different workflows. * **Right-sized requests**: ask for a business reason or an access duration only where it matters, and skip them everywhere else. Less friction for employees, cleaner audit for sensitive apps. * **Multiple provisioning paths**: manual app owner action, automatic add-to-group on the connected IdP, direct add-to-app-instance, or a mixed two-step that combines a group call with a follow-up manual task. * **Day-one defaults**: every workspace ships with an `App owner approval` policy and every app ships with a `Default role`, so any new app accepts access requests as soon as it lands in your inventory. * **Built-in audit**: every App Access record carries its own state machine, visible at any time on the application activity feed, even after the parent Request closes. The feed reads as an event log of only the events that moved the status: request creation, every approval, manual and automatic provisioning, provisioning failures, cancellations, expirations, and planned deprovisioning. ### Common use cases * **Self-service Figma access for the marketing team.** Twelve hires join over a month. The marketing-segmented Role on Figma adds each new starter to the `Marketing` group in Okta automatically as soon as Manager and App owner sign off. No IT touch. * **Time-bounded contractor access.** A freelancer needs the CMS for 30 days. The Role asks for a duration, the App Access record gets a 30-day expiration, and Siit creates the deprovisioning task on the morning it expires. * **Sensitive-app approvals.** Salesforce admin access goes through Finance, Security, then App owner. One `Sensitive admin access` Approval Policy carries the chain, and every Admin Role on Salesforce, Workday, and your HR systems reuses it. * **Partial-SCIM apps.** Your IdP can put a user in the right Notion group, but the editor seat assignment still needs a click in Notion. The mixed two-step provisioning runs the group call automatically and pings the app owner for the seat. * **Multi-instance apps without confusion.** Zoom EU and Zoom US share a brand but live as separate instances. The Role for the EU team adds users to the EU instance and the Role for the US team adds users to the US instance. The requester never sees the routing. * **Quarterly access reviews.** Access records expire on schedule and create deprovisioning tasks, so quarterly reviews start from a clean list instead of a sprawling "who has what" spreadsheet. * **Bulk Role creation from an existing IdP.** Your Okta tenant already has 40 groups mapped to apps. The IdP setup flow lets you pick the groups you need and Siit creates matching Roles in one action, no manual Role creation per group. * **Frictionless default apps.** Everyone gets Slack and the internal wiki on day one. Their Default role is set to `Skip approval`, so Siit provisions access the moment the request comes in, no approval round for an app nobody would ever reject. ### How an access request flows A request follows the same shape end to end whether it comes from Slack, Microsoft Teams, or the portal. The employee picks the app, the Role configuration takes over, and the access lands once approvers sign off. * **Pick the app(s)**: the employee selects one or more applications inside any service form. One request can cover several apps in one go. * **Pick a Role (or auto-route)**: if the app has Roles configured, the employee picks from the list. If only one Role applies, the request routes automatically. Apps without custom Roles use the Default role and ping the app owner manually. * **Answer the Role's form questions, one step per app**: business reason and access duration only appear when the Role asks for them, and each selected application now gets its own step inside the same modal, in sequence. A step with a single available Role and no duration or business reason to collect is skipped automatically. * **Sit through approval**: the Role's Approval Policy fires the cycle and routes the request to the right approvers in the right order, unless the Role is set to `Skip approval`. In that case Siit skips this step entirely and provisions the access right away. * **Get provisioned**: once approvers sign off, Siit provisions the access. Manual app owner task, add-to-group on the connected IdP, add-to-app-instance, or the mixed two-step, depending on the Role. > **Notes** - When a Role is set to `Skip approval`, the App Access card doesn't show an approval cycle section, since none ran. The card only reflects what actually happened.\ > \- On the portal, this step-per-app flow now runs inline: after submitting the request, the employee stays in the same modal instead of receiving a second form afterward. Slack has behaved this way already; the portal now matches it.
### What you control as an admin The configuration sits in two surfaces: workspace-level Approval Policies that define how requests get signed off, and per-app Roles that bind a policy to an audience, a form shape, and a provisioning action. * **Approval Policies**: reusable approval cycles defined once in `Settings → Approval Policies` and reused across many Roles. The default `App owner approval` policy ships ready to use; edit it once and every Default role inherits the change. * **Skip approval**: a fourth option on the Role's approval step, alongside an Approval Policy, auto-accept, and auto-reject. Pick it for the apps everyone gets by default, where an approval round would only add a step, not a decision. Siit moves straight to provisioning: no approver is notified and no approval round opens. * **Roles per app**: each app carries a `Roles` tab where you bind audience, Approval Policy, form questions, and provisioning action together. One app can carry as many Roles as the access pattern needs (`Editor`, `Admin`, `Read-only`, role-by-team, role-by-region). * When an IdP is connected, you can also create Roles in bulk by importing groups directly from Okta, JumpCloud, Microsoft Entra ID, or Google Workspace. Siit lists every group linked to the app, flags any group already used in another Role, and creates all selected Roles in a single action. * **Form questions on the Role**: business reason and duration toggle independently per Role. Duration accepts a free-form value or a fixed cap. * **Provisioning per Role**: pick manual app owner action for full human control, add-to-group for hands-off IdP provisioning, add-to-app-instance when the integration exposes a direct action, or the mixed two-step when the IdP handles part of the access and a human handles the rest. * **Permission scopes**: `Manage policies` controls workspace-level governance; `Define access rules` controls per-app Roles. Separate the two so App owners can build their own Roles without touching the policy library. #### Sequential approval rounds An Approval Policy can chain more than one round of approval. Add as many rounds as the policy needs, for example manager first, then security, then finance, and Siit walks through them one at a time. * **Order matters.** Round 2 only starts once every approver in Round 1 has signed off. * **A rejection stops the chain.** If any round is rejected, every round still waiting behind it is cancelled automatically. No approver downstream ever sees a request that already failed upstream. * **Provisioning waits for the last signature.** App Access provisioning fires only once every round in the policy is approved, so nothing gets granted partway through the chain. Configure rounds from `Settings → Approval Policies → [Policy] → Add round`. Use rounds when a single approval step is not enough for the risk level of an app. A policy for admin level access might need the App owner, then Security, then Finance, each involved only once the previous group has cleared it.
### Where App Access lives Each granted access becomes an App Access record with its own lifecycle, independent of the Request that produced it. The record outlives the Request and stays auditable in two places. * **Application activity feed**: every event that changed an App Access status for that app, in chronological order, from request creation through approvals, provisioning, failures, cancellations, expirations, and planned deprovisioning. App Access records that predate this event log were backfilled, so older history reads the same way as new. The feed is the source of truth for who has access to what, and why. * **App Access filter on the Request list**: surfaces every Request currently carrying at least one App Access record, helpful for triaging requests still in flight. * **Independent lifecycle**: closing the parent Request after provisioning runs does not interrupt the App Access. Scheduled deprovisioning still fires when the date arrives. * **One Request, many App Accesses**: an employee can ask for access to several apps in a single Request. Each app produces its own App Access record with its own state machine. * **Active Users tab**: the app's live roster, reconciled in real time from every source IdP, App Access, and direct adds with each person's access origin shown, so admins can tell why someone has access before revoking it.
### Transparent to your requesters From the requester side, it's a normal access request. They pick the app, optionally a Role, answer the questions the Role asks (often none), and wait. The governance chain, the multi-instance routing, the provisioning method, the audit trail: all admin-side. The requester just gets the access. ### Where App Access Policies fit App Access Policies extend the inventory in [Apps](https://docs.siit.io/data-management/apps) with a governance and provisioning layer on top. Automatic provisioning rides on the IdP integration covered in [IAM](https://docs.siit.io/integrations/iam), with add-to-group calling the connected Identity Provider directly. The approval cycle inside every Approval Policy reuses the mechanics from [Branching and approvals](https://docs.siit.io/workflow/branching-and-approvals), and the per-Role permission scopes (`Manage policies`, `Define access rules`) extend the model in [Roles and permissions](https://docs.siit.io/workspace/roles-and-permissions). ### Canceling or following up on a pending approval The manual actions you already use on standard approvals now extend to App Access approvals too. * **Cancel app access approval**: mark a pending app access approval as expired. A confirmation step prevents accidental cancellations. * **Send reminder**: nudge the pending approver with a one‑click reminder. Siit logs the reminder as an event on the request timeline. Open any request with a pending app access approval and click the **⋯** menu next to the **Waiting approval** status to trigger either action.
> **Note** : Both actions are available to any admin who can access the request, and every cancellation or reminder is recorded so the audit trail stays complete even when a request needed a manual push. # Equipment Equipment is your device inventory—laptops, phones, peripherals, and anything else you assign to people. **Why it matters** * Faster support: link a device to a request to see model, OS, serial number, last check‑in, and owner. * Lifecycle control: track “In service,” “Reserved,” “Outdated,” “Stolen,” etc. * Governance: keep a complete history of assignment and maintenance. **Types and fields** * Equipment types: define categories like Computer, Smartphone, Tablet, Screen, Other device. * Equipment fields: choose the attributes you track (e.g., Model, Serial number, Issue date, Lifecycle, Last maintenance date, Leasing info). Toggle visibility and add custom fields as needed. **Inventory and profiles** * List: filter by type, lifecycle, owner, office location, or last contact date. * Profile: view full details, ownership history, and related requests. Take actions via workflows (assign/reassign, lock/wipe when connected to your MDM). **Kept in sync with your MDM** * **Office location:** if you're connected to Jamf, Microsoft Intune, Kandji, or JumpCloud, Siit maps office location from your MDM through the equipment field mapping, instead of leaving it blank for you to fill in by hand. On Jamf, Siit resolves the location from the buildings your integration already syncs. * **Status follows the owner:** assign an owner to a spare device and Siit automatically moves its status to **In service** unless you changed the status yourself in that same edit. This keeps large fleets from listing devices as "spare" when someone is already carrying them. # Articles Articles are your internal knowledge base inside of Siit. Create or sync content once and use it everywhere—Portal, request replies, workflows, and AI. Siit centralizes your articles, keeps permissions aligned, and tracks usage so you know what helps. **Where articles show up** * Portal → Knowledge base: searchable, categorized content for employees * Request conversation: insert an article in a reply or workflow. Communication; renders as a rich card * AI Assist and IT Agent: answer questions and cite articles as sources; suggest articles in Slack/Teams and the Portal **Ways to add content** * Write directly inside of Siit * Rich editor (headings, lists, images, links) * Draft/Publish, author attribution, categories * Sync from your external Knowledge Base * Notion, Confluence, Slab * Choose spaces/pages to sync; updates stay in sync on a schedule * Save Slack messages to Articles * Add the 🧠 reaction to any Slack message (admins) * Siit captures the message, thread context, and links it as a draft article * You’ll see a success toast in Slack; review and publish in Resources → Articles **Governance and visibility** * Categories: organize by team or topic (IT, HR, Policies, Security * Audience: respect rights and article permissions * Status: Draft vs. Published; edits create a history and keep links stable * Source tracking: each article shows its source (Siit, Slack, Notion, Confluence, Slab) **Analytics** * View requests resolved with article sends to measure deflection * Most suggested articles tell you which questions are being asked most frequently. **Best practices** :bulb: * Title articles as questions employees ask (“How do I reset my Okta MFA?”) * Keep steps short with screenshots or GIFs; add last‑updated and owner * Localize key content or use AI’s language‑aware suggestions * Review top‑used and low‑rated articles monthly; retire duplicates created from Slack saves * Link articles to services that commonly require them for pre‑submission deflection # Sending broadcasts Broadcast messages allow you to send a message to a targeted audience via Slack, Microsoft Teams, or Email. Use them for alerts, announcements, onboarding nudges, or any internal campaign that needs to reach people fast and at scale. Think of of them as internal announcements or mini‑campaigns. You compose a message, define an audience, choose one or more channels, and send. Siit personalizes each message with people data and tracks engagement—deliveries, views, reactions, replies, link clicks, and confirmations—so you know what landed. **Broadcasts are great for** * Company announcements and policy updates * Upcoming events, deadlines, or benefits enrollment * Time‑sensitive alerts like outages or maintenance * New‑hire welcomes and day‑1 instructions * Department‑specific reminders (e.g., expense cutoff, security training) **Key capabilities** * Multi‑channel delivery: Slack DMs, Microsoft Teams messages, and Email * Personalization: insert people fields (first name, department, start date, manager, etc.) directly in the message * Targeted audiences: build rules using People attributes and groups (department, location, legal entity, employment type) * Dynamic or fixed audiences: send to a snapshot right now or keep the rules dynamic for future runs * Scheduling: send now or at a specific date/time with timezone control * Optional confirmation: require recipients to acknowledge receipt (and track who confirmed) * Metrics: sent, delivered, clicked, replied, reacted, confirmed; exportable for reporting * Send as yourself: connect your personal Slack (and Teams, if enabled) so messages arrive from you for higher engagement **After you send** * Track progress in the Communications tab: see state (Live, Scheduled, Finished), sender, content type, sent count, clicks and engagement. * Drill into a send to view recipient‑level status and confirmations. * Resend to non‑viewers or copy the message to create a follow‑up. **Permissions and security** * Role‑based access controls who can create, schedule, and send communications. * Audience building and personalization respect people field visibility. If a field is hidden from your role, you can’t use it. * “Send as yourself” requires the user to authorize their Slack/Teams account; they can disconnect anytime. **Best practices** * Keep it short, lead with the action, and link to a request or knowledge article for details. * Use audiences instead of @channel. It reduces noise and improves relevance. * Personalize lightly—first name and department are often enough. * For critical alerts, require confirmation and schedule an automatic follow‑up to non‑responders. * Time messages with the recipient’s timezone when possible. **Common examples** * Outage alert (IT): audience = All employees; channels = Slack + Email; require confirmation for critical apps. * Security training reminder: audience = Employees in “Engineering” not yet certified; schedule weekly until completion. * New‑hire welcome: audience = Dynamic rule “Start date is today”; channel = Slack DM “from manager” via Send as yourself. * Benefits open enrollment: audience = Legal entity = US; channels = Email + Slack; include deadline and link. # MCP Siit's MCP Server exposes your workspace to AI tools that support the Model Context Protocol: Claude, Codex, Mistral, Cursor and more. {% embed url="" %} The Siit Model Context Protocol (MCP) app allows your third-party AI assistant to access your Siit data and account, so they can read and analyze your requests, and audit and update your service desk.
### Setup Instructions The Siit MCP connector is approved and published in Claude's connector directory. On Claude, browse to Siit in the directory and add it in a few clicks, no server URL to paste or configuration to wire up by hand. Every other MCP-compatible client (Codex, Mistral, Cursor, and more) still connects by adding a custom connector. Tools authenticate with your Siit account via OAuth and can read and act on requests, people, and catalog resources within the data you can access in the Siit admin dashboard. **Server URL:** `https://mcp.siit.io/mcp` \ **Auth:** OAuth 2.1 with dynamic client registration. Actions are performed on behalf of the authenticated user; access is scoped to the same data as in the Siit admin dashboard. **Transport:** Streamable HTTP. For step-by-step connection instructions for each client, see the [Help Center setup guide.](https://help.siit.io/mcp-server-setup-guide)
*** ### What you can do with MCP today Access follows the same scoping as the Siit admin dashboard, **the MCP cannot return data that the authenticated user cannot already see**, or perform writes that the authenticated user cannot already perform in the UI. **Requests** | Tool | Read / Write | Description | | ------------------------ | ------------ | ---------------------------------------------------------------------------------------------- | | `list_requests` | Read | List open requests with full context: requester, status, linked apps, equipment, SLA | | `get_request` | Read | Fetch a single request by ID with all nested details | | `get_request_events` | Read | List the full timeline of events on a request | | `get_request_agent_logs` | Read | Retrieve the AI agent's execution timeline: messages, tool calls, decisions | | `update_request` | Write | Update any field on a request: status, assignee, priority, tags, linked apps, linked equipment | | `send_request_message` | Write | Send a message in a request thread | | `add_request_note` | Write | Add an internal note on a request | | `list_request_tags` | Read | List all request tags | | `get_request_tag` | Read | Fetch a single request tag | | `unarchive_request` | Write | Restore an archived request | | `fetch_attachment` | Read | Fetch an attachment on a request (file metadata and content) | > **Note** : `get_request` and `list_requests` also return `satisfaction_survey_rating` as part of the standard Request payload, so no extra call is needed to pull CSAT data into your AI client. **People** | Tool | Read / Write | Description | | ------------------ | ------------ | ---------------------------------------------------------------------------------- | | `list_people` | Read | List users in your workspace | | `get_person` | Read | Fetch a user with full profile: department, office location, Okta groups, and more | | `create_person` | Write | Create a new user | | `update_person` | Write | Update a user's profile | | `archive_person` | Write | Archive a user | | `unarchive_person` | Write | Restore an archived user | | `merge_person` | Write | Merge two users into one | | `whoami` | Read | Return the currently authenticated user | **CMDB (Apps & Equipments)** | Tool | Read / Write | Description | | --------------------------- | ------------ | ------------------------------------------ | | `list_applications` | Read | List all apps in your catalog | | `get_application` | Read | Fetch a single app with full details | | `create_application` | Write | Add an app to your catalog | | `update_application` | Write | Update an app | | `list_equipments` | Read | List all equipment in your inventory | | `get_equipment` | Read | Fetch a single equipment with full details | | `create_equipment` | Write | Add equipment to your inventory | | `update_equipment` | Write | Update an equipment | | `list_equipment_categories` | Read | List all equipment categories | **Services** | Tool | Read / Write | Description | | ---------------------------------- | ------------ | --------------------------------------------- | | `list_services` | Read | List all services available in your catalog | | `get_services` | Read | Fetch a single service with its configuration | | `create_service` | Write | Create a new service | | `update_service` | Write | Update a service | | `create_service_custom_form_input` | Write | Add a custom form field to a service | | `get_service_custom_form_input` | Read | Fetch a single custom form field | | `update_service_custom_form_input` | Write | Update a custom form field | | `delete_service_custom_form_input` | Write | Permanently delete a custom form field | **Workflow** | Tool | Read / Write | Description | | ------------------------------ | ------------ | ---------------------------------------------------------------------------- | | `list_workflows` | Read | List all workflows | | `get_workflow` | Read | Fetch a single workflow with its configuration | | `create_workflow` | Write | Create a new workflow | | `get_workflow_manifest_schema` | Read | Return the workflow manifest schema (valid triggers, conditions and actions) | **App Access** | Tool | Read / Write | Description | | ------------------------------------------------- | ------------ | ----------------------------------------------------------- | | `list_app_access_roles` | Read | List all app access roles | | `get_app_access_role` | Read | Fetch a single app access role | | `create_app_access_role` | Write | Create an app access role | | `update_app_access_role` | Write | Update an app access role | | `delete_app_access_role` | Write | Delete an app access role | | `get_app_access_role_provisioning_actions_schema` | Read | Return the provisioning actions schema for app access roles | **Knowledge base** | Tool | Read / Write | Description | | ------------------------- | ------------ | ---------------------------------------- | | `list_articles` | Read | List knowledge base articles | | `get_article` | Read | Fetch a single article | | `create_article` | Write | Create a new article | | `update_article` | Write | Update an article | | `publish_article` | Write | Publish an article to the knowledge base | | `unpublish_article` | Write | Revert an article to draft | | `archive_article` | Write | Archive an article | | `unarchive_article` | Write | Restore an archived article | | `list_article_categories` | Read | List knowledge base categories | **Organization** | Tool | Read / Write | Description | | ----------------------- | ------------ | ------------------------------ | | `list_teams` | Read | List all teams | | `get_team` | Read | Fetch a single team | | `list_team_inboxes` | Read | List all inboxes | | `get_team_inbox` | Read | Fetch a single inbox | | `list_departments` | Read | List all departments | | `get_department` | Read | Fetch a single department | | `list_office_locations` | Read | List all office locations | | `get_office_location` | Read | Fetch a single office location | | `list_legal_entities` | Read | List all legal entities | | `get_legal_entity` | Read | Fetch a single legal entity | *** ### Use case examples * **Triage your inbox without opening Siit** : Ask Claude "What are the open P1 requests assigned to no one?" and get a prioritized list with full context — requester department, linked apps, SLA status — then instruct it to assign and update them directly. * **Investigate a request end to end :** Paste a Siit request link into Claude Code and ask it to investigate: who raised it, what app or equipment is involved, what their Okta group is, and whether there are similar open requests. Get a full diagnosis in seconds. * **Run ad hoc analysis across your IT data :** Ask questions like "How many open requests are linked to Slack?" or "Show me all requests from the Engineering team this week" — combining Siit data with other connected tools like Notion or Linear for richer context. * **Draft and send a reply from your AI client** : Ask Claude to draft a response to a specific request based on its context, then send it as a message in the thread — without ever switching tabs. * **Bulk triage after a tool outage** : Ask "List all requests created in the last 2 hours linked to Okta, assign them to the IT team inbox, and tag them as incident." Done in one prompt. *** # Chat Connect Siit to chat platforms where you talk to your employees to automatically track conversations. {% content-ref url="/pages/w0mkqeqZYf44gRyvawDm" %} [Slack](/core-plateform/integrations/slack) {% endcontent-ref %} {% content-ref url="/pages/70J1ibPQd64qIu27HcAy" %} [Microsoft Teams](/core-plateform/integrations/microsoft-teams) {% endcontent-ref %} # IAM Connect Siit to your Identity and Access Management (IAM) platform so users, groups, and application access flow automatically into every request, workflow, and side-panel action. Your IdP becomes the ### Why connect your IdP Your IdP is the source of truth for **who has access to what**. Connecting it to Siit means: * **A directory aligned with access.** Users, groups, and application assignments sync into Siit, so every request carries the full picture of the requester's access. * **One-click actions from any request.** Provision, revoke, add to group, reset password, reset MFA, and more — directly from the request side panel, without switching tabs. * **Workflow-driven provisioning.** Use IdP actions in any workflow: approvals, Day-1 onboarding, access requests, offboarding, SLA escalations. * **AI Agent automation.** Let the IT Agent run sandboxed IdP actions inside playbooks, gated by approvals when needed. * **Audit and traceability.** Every IdP action triggered from Siit is recorded on the request timeline. ### What Siit syncs from your IdP By default, Siit imports: * **Users** — identity, work email, status (active / suspended / deprovisioned) * **Groups** — membership, so workflow conditions can match on group * **Applications** — per-user app assignments and ownership * **Lifecycle events** — user created, user suspended, group membership change Work email is the canonical identifier used to match users across your IdP, HRIS, and other connected tools. ### Supported IAM platforms Siit integrates natively with the four most common IdPs. Each one has its own setup guide: * [Google Workspace](/integrations/iam/google-workspace) * [Microsoft Entra ID](/integrations/iam/microsoft-entra-id) * [Okta](/integrations/iam/okta) * [JumpCloud](/integrations/iam/jumpcloud) Using a different IdP? Reach out via in-app chat — we also support SAML SSO for sign-in from most providers (see SAML - SSO). ### Actions available per IdP The specific actions Siit exposes vary by IdP. Here's what's available today: | Action | Google Workspace | Entra ID | Okta | JumpCloud | | ------------------------------ | ---------------- | -------- | ---- | --------- | | Directory sync (users, groups) | ✓ | ✓ | ✓ | ✓ | | Add / remove from group | ✓ | ✓ | ✓ | ✓ | | suspend / Unsuspend user | ✓ | — | ✓ | ✓ | | Reset password | ✓ | — | ✓ | ✓ | | Reset MFA | — | — | ✓ | ✓ | | Add / remove application | — | — | ✓ | — | | Clear User sessions | ✓ | — | ✓ | — | > **Note** - actions are available from the request side panel, in workflows, and in IT Agent playbooks. Sensitive actions can be gated behind approvals (see Branching & approvals). #### How the sync works * **Initial import** : all users, groups, and app assignments are imported the first time you connect. * **Continuous sync** : Siit refreshes the directory automatically (typically every few hours). * **Real-time actions** : actions triggered from Siit (provision, revoke, reset, etc.) execute immediately and are reflected in the IdP. * **Source of truth rules** : for each People field, pick which system wins if you're also connected to an HRIS. Configure this in **Settings → People → Fields**. * **Alias reconciliation** : the employee mapping in **Settings → People → Fields -> Emails** accepts an `aliases` attribute listing any additional email addresses for a person. An import matching an existing person on any of their addresses, primary or alias, updates that person instead of creating a duplicate. ### HRIS + IdP: the best combination Most customers connect **both** an HRIS and an IdP. Here's how they complement each other: | | IdP | HRIS | | ---------------- | ----------------------------------------- | ----------------------------------------------- | | Source for | Accounts, app access, authentication | Employment data, org structure, lifecycle dates | | Triggers in Siit | User created, group membership change | Start / end dates, probation, anniversaries | | Typical actions | Provisioning, SSO, group / app assignment | Pre-boarding sequences before accounts exist | Connecting both means a full **Day-1 onboarding workflow** can fire on the HRIS start date, then use the IdP to create the account and assign the right apps and groups — and a matching **offboarding** flow can cleanly revoke everything on the HRIS end date. ### Common use cases * **Day-1 provisioning** — Trigger: HRIS Start date. Actions: IdP create user → add to baseline groups → assign app bundle by department. * **Self-service access request** — Service: "Request access to app". Actions: manager approval → IdP Add application to user → notify requester. * **Group membership request** — Trigger: Request submitted (App access form). Actions: approval → IdP Add to group → confirmation DM. * **Password / MFA reset** — Service: "Reset my password" or "Reset MFA". Action: verify identity → IdP reset — gated by approval where required. * **Offboarding on end date** — Trigger: HRIS End date. Actions: IdP revoke sessions → remove app access → suspend account → equipment pickup request. * **Side-panel one-click actions** — From any request, agents can run IdP actions directly on the requester without leaving Siit. ### SSO is separate This section covers IdP as a **directory and action source** (people sync + provisioning). If you're only looking to let users sign in to Siit with Google, Microsoft, Okta, or JumpCloud, see SAML - SSO. Most customers do both: connect the IdP here to unlock actions, and enable SSO in Settings → Security → SSO for authentication. ### Getting started 1. Go to **Settings → Integrations** and pick your IdP in the library. 2. Authorize the connection (each IdP has its own flow — see the per-platform guides). 3. Review imported users, groups, and apps. Adjust mapping in **Settings → People → Fields** if needed. 4. Set the source of truth per field if you're also connected to an HRIS. 5. Try your first action from a request side panel, or build a workflow in **Workflows → New**. Pick your IdP above to see the exact setup steps. # Google Workspace Connect Google Workspace to Siit to sync your users and groups, and power group management actions from every request and workflow.
Connect Google Workspace to manage groups directly from any request. Add or remove users from Google Groups in the side panel, in workflows, or via IT Agent, and feed Day-1 onboarding flows from your HRIS-driven org structure. ### What you get * **Live directory** — Google Workspace users sync into Siit with email, name, org unit, and group memberships. * **Group management actions** — add or remove users from Google Groups directly from request side panels, workflows, and IT Agent playbooks. * **Audit trail** — every group change triggered from Siit is logged on the request timeline. * **Source for onboarding and access requests** — pair Google with an HRIS to run Day-1 flows that place new hires into the right distribution lists and access groups automatically. > **Scope note** — Siit's Google Workspace integration focuses on **directory sync and group management**. User lifecycle actions (create, suspend, delete) are not currently exposed as native Siit actions for Google Workspace — if you need those, pair Google Workspace with Okta, Entra ID, or JumpCloud, or use the IT Agent with custom webhooks. ### What syncs from Google Workspace | Category | Fields | | ----------- | ---------------------------------------------------- | | Identity | Full name, primary email, aliases, Google user ID | | Org context | Organizational unit, job title (if set in Directory) | | Groups | Group memberships, group ownership | Work email (the primary Google email) is the canonical identifier. ### Actions available * **Google → Add user to group** — add a user to a Google Group. Available in side panel, workflows, and IT Agent. * **Google → Remove user from group** — remove a user from a Google Group. Available in side panel, workflows, and IT Agent. Both actions can be gated behind approvals when used in workflows or IT Agent playbooks. ### Before you connect * You'll need a **Google Workspace Super Admin** account to grant the initial OAuth consent. Consent is granted once at the workspace level. * Decide which admin account will own the connection. The integration continues to work after individual admins change, but re-authorization requires a Super Admin. * Choose whether Siit should have **read-only directory access**, or also **group management** scope. Without the group management scope, add/remove actions won't be available. ### Connect Google Workspace 1. In Siit, go to **Settings → Integrations**. 2. Find **Google Workspace** in the IAM section and click **Connect**. 3. You'll be redirected to Google to sign in. Sign in with a Super Admin account. 4. Review the requested OAuth scopes: * Read directory (users, org units, groups and memberships) * Optional: manage group memberships — required for add / remove actions 5. Accept the consent and you'll be redirected back to Siit. 6. Siit runs an initial import of users and groups (can take a few minutes for large workspaces). 7. Review the imported data and click **Finish setup**. > **Tip** — If your Google Workspace has **app access control** restrictions, a Super Admin may need to explicitly allow Siit in Security → API controls → App access control → Manage third-party app access. Otherwise the OAuth flow will fail silently or with a "restricted" message. ### After the connection * **Check your People list** — confirm users imported correctly. The count should match Directory users (excluding suspended, unless you opted to include them). * **Scope the groups** — by default all groups are synced. In **Settings → Integrations → Google Workspace**, you can scope to specific groups or org units if you don't want the entire directory tree. * **Try an action from a request** — open any request, and use the side panel Apps section to add/remove the requester from a Google Group. * **Build a workflow** — a good first workflow: an access request that adds the requester to a group after manager approval. ### Sync frequency Google Workspace data refreshes automatically every few hours. Trigger an immediate refresh from **Settings → Integrations → Google Workspace → Sync now**. Actions run on demand, immediately, when triggered from Siit. ### Common workflows **Access request.** *Trigger: Request submitted (service = "Request group access"). Actions: manager approval → Google add to group → DM requester.* **Day-1 onboarding (with HRIS).** *Trigger: Start date. Actions: Google add to onboarding@ group and dept-specific groups → notify manager.* **Offboarding on end date.** *Trigger: End date. Actions: Google remove from all groups → create equipment pickup request → DM manager.* **Project access provisioning.** *Trigger: Request submitted with form value Project = "Phoenix". Action: Google add to phoenix-team@ group.* ### Troubleshooting **Connection fails with "app not authorized".** Super Admin hasn't allowed Siit in Google's third-party app access control. Ask a Super Admin to approve Siit in Security → API controls → App access control. **Users missing from Siit.** Check whether suspended users are excluded — by default they are. Adjust the filter in **Settings → Integrations → Google Workspace**. **Add to group action fails.** The OAuth scope for group management wasn't granted at install time. Re-authorize the connection and accept the group management scope. **Group isn't visible as an option.** The group may be scoped out. Check the group scope setting in **Settings → Integrations → Google Workspace**, or ensure it's a Google Group (not a shared label or team drive). **A user isn't in the group after the action ran.** Check the request timeline — if the action succeeded, Google may be propagating the change (some distribution groups take a minute). If it failed, the error is shown inline. # Microsoft Entra ID Connect Microsoft Entra ID to Siit to sync your users, groups, and application assignments, and expose Entra actions directly inside Siit workflows, request side panels, and the IT Agent.
### What you get * **Live directory** — Entra users, groups, and Enterprise Applications sync into Siit with full attribute coverage. * **One-click actions from any request** — add to group, remove from group, revoke sessions, and more, from the request side panel. * **Workflow-driven provisioning** — use Entra actions in any workflow: access requests, Day-1 onboarding, offboarding, and more. * **Microsoft 365 context** — pairs well with the Microsoft Teams integration so you get a fully unified employee experience across chat, identity, and requests. ### What syncs from Entra ID | Fields | | ---------------------------------------------------------------- | | Display name, user principal name (UPN), work email, object ID | | Job title, department, manager, office location, usage location | | Security groups and Microsoft 365 groups, memberships, ownership | | Enterprise Applications assigned to users | | Active / blocked / deleted | Work email (mail attribute or UPN) is the canonical identifier. ### Actions available * **Add user to group** * **Remove user from group** * **Assign application to user** * **Remove application from user** * **Revoke user sessions** * **Block / unblock sign-in** * **Reset password** (temporary password, must be changed on next sign-in) * **Delete user** (soft delete — recoverable for 30 days in Entra) Actions are available from the request side panel, in workflows, and in IT Agent playbooks. Sensitive actions can be gated behind approvals. ### Before you connect * You'll need an **Entra ID Global Administrator** (or Privileged Role Administrator) to grant admin consent for the required permissions. * Siit is installed as an Enterprise Application in your Entra tenant via OAuth consent — no certificates, manifests, or manual app registrations required. * If your tenant blocks user consent for third-party apps, admin consent must be granted explicitly during the install flow. ### Connect Entra ID 1. In Siit, go to **Settings → Integrations**. 2. Find **Microsoft Entra ID** in the IAM section and click **Connect**. You'll be redirected to Microsoft. 3. Sign in with a Global Administrator account. 4. Review and grant admin consent for the requested Microsoft Graph permissions: * `User.Read.All` — read user profiles * `Group.Read.All` + `GroupMember.ReadWrite.All` — read groups, manage memberships * `Directory.Read.All` — read org structure * `Application.Read.All` — read Enterprise Applications * `User.ReadWrite.All` — for user management actions (activate/suspend, reset password) * `UserAuthenticationMethod.ReadWrite.All` — for MFA / password actions 5. Once consent is granted, Microsoft redirects you back to Siit. 6. Siit runs an initial import of users, groups, and applications. 7. Review the imported data and click **Finish setup**. > **Tip** — Install with a dedicated service / break-glass Global Admin account if your security policy prefers it. The OAuth grant is tenant-wide and survives the installing admin leaving the company. ### After the connection * **Check your People list** — confirm the user count matches your Entra active users. * **Scope the groups** — by default all groups are synced. In **Settings → Integrations → Microsoft Entra ID**, you can scope to specific groups or OUs. * **Try an action from a request** — open any request and use the side panel to add/remove the requester from an Entra group. * **Build a workflow** — a classic starter: manager approval → Entra add to group → DM confirmation. ### Sync frequency Entra data refreshes automatically every few hours. Trigger an immediate refresh from **Settings → Integrations → Microsoft Entra ID → Sync now**. Actions run on demand, immediately, when triggered. ### Common workflows **Access request.** *Trigger: Request submitted (service = "Request app access"). Actions: manager approval → Entra assign application → DM requester.* **Group membership request.** *Trigger: Request submitted. Actions: approval → Entra add to group → confirmation message.* **Day-1 onboarding (with HRIS).** *Trigger: Start date. Actions: Entra add to baseline groups → assign department app bundle → notify manager.* **Offboarding on end date.** *Trigger: End date. Actions: Entra revoke sessions → remove app assignments → block sign-in → equipment pickup request.* **Session revoke on suspicious activity.** *Trigger: Request submitted (service = "Report lost device"). Action: Entra revoke user sessions immediately → create follow-up incident.* ### SSO is separate Connecting Entra here is about using it as a **directory and action source**. If you only want to let users sign in to Siit with their Microsoft account, see SAML - SSO. Most customers do both. ### Troubleshooting **Admin consent error during install.** You signed in with an account that doesn't have Global Admin rights — or your tenant requires explicit admin consent. Retry with a Global Admin account. **"Insufficient privileges" when running an action.** The corresponding Graph permission was not granted at install time (e.g., `UserAuthenticationMethod.ReadWrite.All` is missing for password reset). Reconnect Entra and re-grant the full permission set. **Users missing from Siit.** Check whether guest accounts and deactivated users are excluded (they are, by default). Adjust the filter in **Settings → Integrations → Microsoft Entra ID** if needed. **Group not available as a target.** The group may be out of scope, or it's a distribution group that doesn't support programmatic membership management via Graph. Check group type in Entra. **Connection shows as "needs reauthorization".** An admin revoked the Siit Enterprise Application's consent, or a conditional access policy is blocking the token refresh. Reconnect the integration. # Okta Connect Okta to Siit to sync your users, groups, and application assignments, and expose the full set of Okta actions directly inside Siit workflows, request side panels, and the IT Agent.
### What you get * **Live directory** — Okta users, groups, and app assignments sync into Siit with full attribute coverage. * **One-click actions from any request** — provision, revoke, add to group, reset password, reset MFA, directly from the request side panel. * **Workflow-driven automation** — use Okta actions in any workflow: approvals, Day-1 onboarding, access requests, offboarding, SLA escalations. * **IT Agent native support** — Okta actions are first-class in IT Agent playbooks, with optional approval gating on every action. * **Audit trail** — every action triggered from Siit is logged on the request timeline. ### What syncs from Okta | Category | Fields | | ------------ | --------------------------------------------------------------------------- | | Identity | Display name, email, login, Okta user ID, employee number | | Profile | Job title, department, manager, location (city, country), custom attributes | | Groups | Okta groups, memberships, types (built-in, custom, app-assigned) | | Applications | App assignments per user, including SAML, OIDC, and SWA apps | | Status | Active, provisioned, staged, suspended, deprovisioned | Work email is the canonical identifier. ### Actions available Siit exposes the following Okta actions — available in the request side panel, in workflows, and in IT Agent playbooks. Each can be gated behind an approval. **User actions** * Activate user * Suspend user * Deprovision user * Reset password (sends reset email or sets temp password) * Reset MFA (clears enrolled factors, forces re-enrollment) * Revoke sessions (force sign-out everywhere) * Restore sessions **Group actions** * Add user to group * Remove user from group **Application actions** * Assign application to user * Remove application from user ### Before you connect * You'll need an Okta **Super Admin** (or an admin with Read + Manage permissions for Users, Groups, and Applications) to authorize the connection. * Decide whether Siit should use **OAuth** (recommended — managed via an Okta service app) or an **API token** (legacy — tied to an individual admin account). * Make sure Siit's requested scopes are allowed by your Okta tenant's API token / OAuth policy. ### Connect Okta #### Option A — OAuth (recommended) 1. In Siit, go to **Settings → Integrations**. 2. Find **Okta** in the IAM section and click **Connect**. 3. Enter your Okta **domain** (e.g., `yourcompany.okta.com`). 4. You'll be redirected to Okta to sign in and consent. Sign in with a Super Admin account. 5. Review the requested scopes: * `okta.users.read`, `okta.users.manage` * `okta.groups.read`, `okta.groups.manage` * `okta.apps.read`, `okta.apps.manage` * `okta.sessions.manage` 6. Accept and you'll be redirected back to Siit. 7. Siit runs an initial import of users, groups, and apps. 8. Review the imported data and click **Finish setup**. #### Option B — API token (legacy) Use this only if OAuth isn't an option in your tenant. 1. In Okta, go to **Security → API → Tokens → Create Token**. Name it "Siit integration" and copy the token. 2. In Siit → **Settings → Integrations → Okta → Connect**, choose **API token** and paste the token plus your Okta domain. 3. Click **Authorize** and follow the initial import flow. > **Tip** — API tokens inherit the permissions of the admin who created them, and they expire after 30 days of inactivity. OAuth is less fragile and survives admin changes — we recommend it for all new installs. ### After the connection * **Check your People list** — confirm user counts match Okta's active users. * **Scope the groups and apps** — by default everything is synced. In **Settings → Integrations → Okta**, you can scope to specific groups, apps, or user types if you don't want the entire tenant. * **Try one-click actions** — open any request, and use the side panel Apps section to run Okta actions on the requester. * **Build your first workflow** — the classic starter: access request → manager approval → Okta assign application → DM requester. ### Sync frequency Okta data refreshes automatically every few hours. Trigger an immediate refresh from **Settings → Integrations → Okta → Sync now**. Actions run on demand, immediately, when triggered. **App removals sync too.** If an app is deleted in Okta, it's marked **Restricted** in Siit on the next sync, so your catalog doesn't keep offering an app that no longer exists in your identity provider. This only applies to apps that were discovered and are managed through the Okta integration; apps added directly in Siit or sourced from another integration keep their current status. ### Common workflows **App access request.** *Trigger: Request submitted (service = "Request app access"). Actions: manager approval → Okta assign application → DM requester.* **Group access request.** *Trigger: Request submitted. Actions: approval → Okta add to group → confirmation.* **Password reset (self-service).** *Trigger: Request submitted (service = "Reset password"). Actions: identity verification → Okta reset password (emails user) → close request.* **MFA reset with manager approval.** *Trigger: Request submitted (service = "Reset MFA"). Actions: manager approval → Okta reset MFA → DM requester with re-enrollment instructions.* **Day-1 onboarding (with HRIS).** *Trigger: Start date. Actions: Okta activate user → add to baseline groups → assign department app bundle → notify manager.* **Offboarding on end date.** *Trigger: End date. Actions: Okta revoke sessions → remove from all groups → deprovision user → equipment pickup request.* **Suspicious activity response.** *Trigger: Request submitted (service = "Report lost device"). Actions: Okta revoke sessions → suspend user → create incident for security team.* ### IT Agent integration Okta actions are available inside IT Agent playbooks via slash commands: * `/okta reset multi-factor` *(approval available)* * `/okta reset password` *(approval available)* * `/okta add to group` *(approval available)* * `/okta add applications` *(approval available)* This means an IT Agent playbook can resolve a full password reset or access request end-to-end, with approval gates where you need them. See IT Agent. ### Troubleshooting **Connection fails on authorize.** The admin doesn't have Super Admin rights, or the tenant blocks the requested scopes. Try with a Super Admin, or check Security → API → Authorization Servers for scope restrictions. **Users missing from Siit.** Check whether suspended, deactivated, and staged users are excluded (they are by default). Adjust the status filter in **Settings → Integrations → Okta** if needed. **Action fails with "insufficient scope".** The OAuth grant is missing a scope. Reconnect Okta and accept the full scope set. **Action fails silently in a workflow.** Open the workflow run in **Workflows → \[workflow] → Runs** — errors from Okta are shown inline with the Okta response code. **API token expired.** If you're on API token auth, rotate the token (Okta → Security → API → Tokens) and update it in Siit. Consider migrating to OAuth to avoid future expirations. **Group/app not visible in the action picker.** It's likely scoped out. Review scoping in **Settings → Integrations → Okta**, or confirm the object is actually an Okta group / app and not an Okta Workflows object. **Rate limits.** Large tenants may occasionally hit Okta rate limits during initial sync. Siit retries automatically; contact support if syncs are consistently slow. # JumpCloud Connect JumpCloud to Siit to sync your users and groups, and run identity actions — add to group, reset password, reset MFA — directly from Siit request side panels, workflows, and IT Agent playbooks.
### What you get * **Live directory** — JumpCloud users and User Groups sync into Siit with profile attributes and group memberships. * **Identity actions from any request** — add to group, reset password, reset MFA, directly from the request side panel. * **Workflow-driven automation** — use JumpCloud actions in any workflow, with approvals where needed. * **IT Agent native support** — JumpCloud actions are first-class in IT Agent playbooks. ### What syncs from JumpCloud | Category | Fields | | -------- | --------------------------------------------------------- | | Identity | First name, last name, email, username, JumpCloud user ID | | Profile | Job title, department, manager, location, employee type | | Groups | User Groups, memberships | | Status | Active / suspended | Work email is the canonical identifier. ### Actions available * **Add user to group** * **Remove user from group** * **Reset password** (sends reset email) * **Reset MFA** (clears enrolled factors, forces re-enrollment) * **Suspend user** * **Activate user** Actions are available from the request side panel, in workflows, and in IT Agent playbooks. Sensitive actions can be gated behind approvals. ### Note on device and system management JumpCloud can also manage devices, SSH keys, LDAP, and RADIUS. Siit's integration currently focuses on **identity** (users, groups, password / MFA). If you rely on JumpCloud for device management and want those actions in Siit, reach out via in-app chat — we're collecting interest. ### Before you connect * You'll need a JumpCloud **Administrator** account with at least the **User Admin with Billing** role (or higher) to generate an API key. * Decide which admin's API key Siit will use. The integration inherits that admin's permissions. ### Connect JumpCloud 1. In JumpCloud, generate an API key: * Sign in to the JumpCloud Admin Portal. * Click your initials (top right) → **My API Key**. * Click **Generate New API Key** (if you don't have one) and copy the key. 2. In Siit, go to **Settings → Integrations**. 3. Find **JumpCloud** in the IAM section and click **Connect**. 4. Paste the API key and your JumpCloud organization ID (visible under **Settings → Organization** in JumpCloud), then click **Authorize**. 5. Siit runs an initial import of users and groups. 6. Review the imported data and click **Finish setup**. > **Tip** — API keys in JumpCloud are tied to a specific admin user. Use a dedicated service admin account rather than a personal one so the integration survives admin turnover. ### After the connection * **Check your People list** — confirm user counts match JumpCloud's active users. * **Scope the groups** — in **Settings → Integrations → JumpCloud**, you can scope which User Groups are synced if you only want a subset. * **Try an action from a request** — open any request and use the side panel to add the requester to a group. * **Build a workflow** — a classic starter: access request → manager approval → JumpCloud add to group → DM confirmation. ### Sync frequency JumpCloud data refreshes automatically every few hours. Trigger an immediate refresh from **Settings → Integrations → JumpCloud → Sync now**. Actions run on demand, immediately, when triggered. ### Common workflows **Access request.** *Trigger: Request submitted (service = "Request group access"). Actions: manager approval → JumpCloud add to group → DM requester.* **Password reset (self-service).** *Trigger: Request submitted (service = "Reset password"). Actions: identity verification → JumpCloud reset password → close request.* **MFA reset.** *Trigger: Request submitted (service = "Reset MFA"). Actions: manager approval → JumpCloud reset MFA → DM requester with re-enrollment instructions.* **Day-1 onboarding (with HRIS).** *Trigger: Start date. Actions: JumpCloud add to baseline groups → notify manager.* **Offboarding on end date.** *Trigger: End date. Actions: JumpCloud remove from all groups → suspend user → equipment pickup request.* ### IT Agent integration JumpCloud actions are available inside IT Agent playbooks via slash commands: * `/jumpcloud add to group` * `/jumpcloud reset user password` * `/jumpcloud reset user mfa` See IT Agent for playbook examples. ### Troubleshooting **Connection fails with "invalid credentials".** The API key is wrong, revoked, or the admin owning it has been deactivated. Regenerate in JumpCloud and update in Siit. **Users missing from Siit.** Check whether suspended users are excluded (they are by default) and whether the admin's role has access to all user groups you expect. **Group not visible in the action picker.** It's likely scoped out. Review group scope in **Settings → Integrations → JumpCloud**, or confirm the group exists in JumpCloud (User Group, not System Group). **Reset password action didn't send an email.** JumpCloud sends the reset to the user's primary email; confirm the email is valid and the user's account is active. **Action fails in a workflow.** Open the workflow run in **Workflows → \[workflow] → Runs** — the JumpCloud error response is shown inline. Common causes: admin role lacks MFA management permission, or the user is already suspended. # Ticketing Connect Siit to your ticketing and issue-tracking tools so requests flow cleanly between Siit and the systems where engineering, IT specialists, and other back-office teams do their work. ### Why connect a ticketing tool Siit is where employees submit and track requests. But not every request ends in Siit — some need to be picked up by an engineering team in Jira, a platform team in Linear, or a specialist queue in a dedicated ITSM tool. Connecting Siit to your ticketing tools means: * **One-click escalation.** From any Siit request, create a linked ticket in the right tool — with all the context already attached. * **Configurable two-way sync.** Choose exactly what flows between Siit and the external ticket — resolution, assignee, notes and messages and set each direction independently, so both sides stay aligned without over-syncing. * **Workflow automation.** Create tickets automatically when specific requests come in (e.g., "new app integration request" → Jira issue for engineering). * **No duplication.** Employees stay in Siit (Slack / Teams / Portal). Specialists stay in their tool. The link keeps both sides honest. * **AI Agent escalation.** The IT Agent can create tickets in the right tool as part of a playbook — with approval gates for anything sensitive. ### Supported ticketing tools Siit integrates natively with the most common ticketing and issue-tracking platforms: * **Jira** * **Jira Service Management** * **Linear** * **Zendesk** * **Freshservice** * **Freshdesk** * **ServiceNow** * **Asana** * **Github** * **Gitlab** * **Clickup** * **Intercom** * **Trello** * **Kustomer** Using a different ticketing tool? You can build custom integrations using Webhooks — call any endpoint with your request payload and post updates back via the Siit API. ### What each integration covers | Capability | Jira | Jira Service Mgmt | Linear | Zendesk | Freshservice | Intercom | Trello | | ----------------------------------- | ---- | ----------------- | ------ | ------- | ------------ | -------- | ------ | | Create ticket from a Siit request | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | Configurable two-way sync | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | Link preserved on both sides | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | Available in workflows | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | Available in IT Agent | ✓ | ✓ | ✓ | ✓ | — | ✓ | ✓ | | Available in the request side panel | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ### How escalation works The fastest way to use ticketing in Siit is **Escalate ticket** from the request side panel. From any Siit request, click **Escalate ticket**, pick the destination (Jira, JSM, Linear, etc.), fill in the required fields (project, issue type, summary, assignee if needed), and submit. The new ticket is created in the target tool, pre-populated with the Siit request context, and linked both ways. For tools with bi-directional sync (Jira, JSM, Linear), status changes on the external ticket update the Siit request's external status field automatically. You can use this as a condition in workflows ("when the linked Jira issue is Done, set Siit request to Resolved"). ### Configuring what syncs Sync is no longer all-or-nothing. For every supported ticketing integration, you decide which events keep Siit and the external ticket aligned. Go to Settings → Integrations → \[tool] → Settings. You’ll see two independent sections: **From Siit to the ticket** : when a Siit request is resolved, reassigned, gets a note, or gets a new message, mirror it to the linked ticket. **From the ticket to Siit** : when the external ticket is resolved, reassigned, gets a note, or gets a new message, mirror it back to Siit. Each event isn't simply on/off, you choose the behaviour. **Resolved**: do nothing (default) or resolve the other side. \ **Assignee**: do nothing (default) or match. \ **Note**: escalate as a note (default), escalate as a message, or do nothing. \ **New message**: escalate (default) or do nothing. \ You can also map how a resolved Siit request translates into a status in the destination tool. ### Using ticketing actions in workflows Ticketing actions are available as workflow steps alongside every other Siit action. Some useful patterns: * **Auto-escalate by category.** *Trigger: Request submitted. Condition: Service = "App bug report". Action: Create Jira issue in ENG project → Set Siit status to Waiting.* * **Approval → external ticket → sync.** *Trigger: Request submitted (service = "New integration"). Actions: manager approval → Create Linear issue → DM requester with the Linear issue link.* * **Incident swarm.** *Trigger: Tag "incident" added. Actions: Create linked Jira issue in INC project → Post to #it-incidents with both links.* * **Specialist handoff.** *Trigger: Request assigned to "Network" inbox. Action: Create Freshservice ticket in Network queue → Note on Siit request with the ticket URL.* ### IT Agent integration The IT Agent can create tickets autonomously inside a playbook, using slash commands: * `/jira create issue` *(approval available)* * `/zendesk create ticket` *(approval available)* A common playbook: an employee reports a broken integration in Slack → IT Agent gathers context → requests manager approval → creates a Jira issue → posts the link back to the employee. See IT Agent. ### Common use cases * **Bug reports from employees** — employee submits a bug in Slack, Siit auto-creates a Jira issue in the right project, links stay in sync until the fix ships. * **New app integration requests** — request in Siit → manager approval → Linear issue for the platform team → Siit closes automatically when the Linear issue is marked Done. * **ITSM handoffs** — a request that needs network, security, or facilities expertise is escalated from Siit to Jira Service Management / Freshservice, where the specialist team already works. * **Incident management** — a major incident opens in Siit, creates tracker issues in Jira, and ensures everyone is working from a single source of truth. * **Project-linked requests** — requests tied to an engineering project are linked to the matching Linear project so the full trail is visible from both sides. ### Connecting a ticketing tool Each ticketing tool has its own connection flow, but the pattern is the same: 1. Go to **Settings → Integrations** and find your ticketing tool in the library. 2. Authorize the connection (OAuth or API token, depending on the tool). 3. Map default projects, issue types, and priorities — so escalations pre-fill sensibly. 4. Configure status sync rules if the integration supports them (e.g., which Jira statuses map to Siit's Waiting / Resolved). 5. Test by escalating a sample request from Siit to your ticketing tool. ### Tips * **Use a dedicated service account** where possible (e.g., a Jira "Siit Integration" user). The integration inherits that account's permissions, and a service account survives admin turnover. * **Start with one project or queue.** Don't map every Jira project or Linear team on Day 1 — pick the one or two your team escalates to most often, and expand from there. * **Keep the Siit request as the canonical employee-facing view.** Employees shouldn't need a Jira or Linear account to track their request — Siit stays their single surface. * **Use status sync to close the loop.** Nothing frustrates employees more than a ticket that feels abandoned. Mapping "Done" in Jira / Linear to "Resolved" in Siit keeps the requester informed automatically. # Jira Connect Jira to Siit to escalate requests into Jira issues with one click, keep statuses in sync between both tools, and automate Jira issue creation from any workflow or AI Agent playbook.
## Jira #### What you get * **One-click escalation from any request.** Click **Escalate ticket** in the request side panel, pick a Jira project and issue type, and a linked issue is created with the Siit context pre-filled. * **Configurable two-way sync.** Choose exactly what cascades between a Siit request and its linked Jira issue: resolution, assignee, notes, and messages, each opt-in per direction. * **Escalation defaults per board.** Set the default request type, status, and assignee behavior Siit applies when escalating, and let agents override them at escalation time. * **Workflow-driven issue creation.** Use **Create Jira issue** as a workflow step, with field mapping and approval gating where needed. * **IT Agent native support.** `/jira create issue` is available inside IT Agent playbooks, with optional approval. * **Custom field mapping.** Map Siit form fields and request attributes to your Jira custom fields, so escalated tickets land with the right context every time. * **Audit trail.** Every Jira action triggered from Siit is recorded on the request timeline. #### How it works When a Siit request needs engineering or specialist work, you escalate it to Jira: 1. From the request side panel, click **Escalate ticket** and pick **Jira**. 2. Choose the project, issue type, and any required fields. Escalation defaults and custom fields configured in **Settings → Integrations → Jira** pre-fill automatically, and you can adjust them before creating the issue. 3. Submit. Siit creates the Jira issue, links it back to the Siit request, and posts the link on both sides. 4. From there, updates flow between the two according to your sync configuration (see below). The same flow is available in workflows (as a **Create Jira issue** action) and in IT Agent playbooks. #### Sync configuration Sync is set at the integration level and is fully bi-directional. In **Settings → Integrations → Jira → Settings**, you get one table per direction. Each row is an event, and you choose how Siit reacts to it. **From Siit to Jira** controls what happens on the Jira issue when the linked Siit request changes: * **When marked as resolved** — resolve the Jira issue, or do nothing. * **When assignee changes** — match the assignee on Jira where possible, or do nothing. * **When a note is added** — push it to Jira, or do nothing. * **When a new message is posted** — push it to Jira, or do nothing. **From Jira to Siit** controls what flows back to the Siit request when the Jira issue changes: * **When marked as resolved** — resolve the Siit request, or do nothing. * **When assignee changes** — match the assignee on Siit, or do nothing. * **When a note is added** — import it into the request, or do nothing. * **When a new message is posted** — import it into the request, or do nothing. Each option is opt-in, so nothing cascades unless you turn it on. Defaults are capability-aware: Siit only exposes the behaviors Jira can actually honor, which means you never configure something the tool cannot do. #### Escalation defaults Escalation defaults are the values Siit pre-fills when escalating a request to a given Jira board. Agents can override them at escalation time. Configure them per project under **Settings → Integrations → Jira**: * **Request type** — the default issue type created on escalation. * **Status** — the default status. Available statuses depend on the selected request type. * **Match assignee** — when enabled, Siit maps the Siit assignee to the Jira assignee where a match exists. #### Custom field mapping Map Siit data to Jira custom fields so escalated issues arrive with the right metadata: request ID, requester, service, priority, anything you need. Set this up in **Settings → Integrations → Jira → Custom mapping**. For the full setup guide, see [Custom field mapping](https://help.siit.io/custom-field-mapping). Field options now include fields on the board's edit screen, not just the create screen. When Jira rejects a specific field on write, Siit still submits the fields the board accepts instead of failing the whole escalation. #### Before you connect * A Jira admin (or Jira site admin) to authorize the connection. * A clear idea of which Jira project(s) you want to escalate to. Start with one, then expand. * Optional: a dedicated "Siit Integration" Jira user, so the integration survives admin turnover. #### Connect Jira 1. In Siit, go to **Settings → Integrations**, find **Jira** in the Ticketing section, and click **Connect**. 2. Sign in to your Jira site as an admin and approve the requested scopes. 3. Pick the Jira project(s) you want available for escalation. 4. Set escalation defaults, sync configuration, and field mapping. 5. Test by escalating a sample request from Siit to Jira. For the detailed walkthrough, see our Help Center guide: [Jira integration setup](https://help.siit.io/jira-integration). #### After the connection * **Try the side panel.** From any request, click **Escalate ticket → Jira** and create a test issue. * **Set your sync rules.** In **Settings → Integrations → Jira → Settings**, decide what cascades in each direction (resolution, assignee, notes, messages). * **Set escalation defaults.** Pick the default request type, status, and assignee behavior for each board. * **Configure field mapping.** Map your Siit fields to the Jira custom fields you care about. * **Build your first workflow.** A common starter: "when service = 'Bug report', auto-create a Jira issue in the ENG project and notify the requester." #### Common workflows **Bug report auto-escalation.** *Trigger: Service = "App bug report". Actions: Create Jira issue in ENG project → Set Siit status to Waiting → Notify requester with the Jira link.* **Approval-gated engineering request.** *Trigger: Service = "New integration". Actions: Manager approval → Create Jira issue in PLATFORM project → DM requester with the Jira link.* **Auto-resolve on Jira completion.** *Trigger: Linked Jira issue resolved. Actions: Set Siit request to Resolved → Notify requester.* (Enable "When marked as resolved → Resolve" on the From Jira to Siit direction.) #### IT Agent integration Inside an IT Agent playbook, use `/jira create issue` to let the agent escalate autonomously, with approval gating on the action when you want a human in the loop. A common playbook: an employee reports a broken integration in Slack → IT Agent gathers context → requests manager approval → creates a Jira issue → posts the link back to the employee. See IT Agent for playbook examples. #### Tips * **Use a dedicated service account** for the Jira connection so it survives individual admin turnover. * **Start with one project.** Mapping fields, defaults, and sync rules for one well-used project first is faster and lower-risk than connecting everything at once. * **Keep Siit as the employee surface.** Employees shouldn't need a Jira account to track their request. The Siit request stays their canonical view; the linked Jira issue is internal. * **Turn on only the sync you need.** Since every cascade is opt-in, enable the events your team relies on and leave the rest off to avoid noise. #### Help Center guides * [Jira integration setup](https://help.siit.io/jira-integration) — step-by-step setup with screenshots * [Two-way sync configuration](https://help.siit.io/jira-sync-configuration) — how each sync event behaves * [Jira guide](https://help.siit.io/jira-guide) — day-to-day usage and best practices * [Custom field mapping](https://help.siit.io/custom-field-mapping) — map Siit data to Jira custom fields #### Troubleshooting **"Authorization failed" on connect.** The admin signing in lacks Jira admin rights, or the Jira site has restricted third-party app installs. Try with a site admin. **Project missing from the destination picker.** The Siit Jira user lacks Browse Projects permission for that project. Update permissions in Jira and re-sync. **A board shows as unreachable.** The Jira board was deleted or archived. Siit flags it as unreachable in the collections list so escalations don't fail silently. Remove it or point the escalation at a live board. **Custom field not appearing in mapping.** The field may be tied to a specific issue type or screen scheme. Confirm the field is on the issue type's create or edit screen, then re-run the mapping step. **A sync event isn't cascading.** Check the sync table in **Settings → Integrations → Jira → Settings**. If the event is set to "Do nothing" in that direction, it won't cascade. Note that some behaviors are unavailable on Jira by design and won't appear as options. **"Issue created" but no link in Siit.** The Jira issue was created but the back-link save failed. Open the request timeline: the Jira issue key is logged. Manually re-link if needed, then check Siit's connection token validity. # Jira Service Management Connect Jira Service Management (JSM) to Siit to escalate employee requests into JSM tickets with one click. JSM is the right choice when specialist teams
### What you get * **One-click escalation from any request.** Click **Escalate ticket** in the request side panel, pick a JSM service project and request type, and a linked ticket is created with the Siit context pre-filled. * **Configurable two-way sync.** Choose exactly what cascades between a Siit request and its linked JSM ticket: resolution, assignee, notes, and messages, each opt-in per direction. * **Escalation defaults per project.** Set the default request type, status, and assignee behavior Siit applies on escalation, overridable at escalation time. * **Customer Request Type on escalation.** Choose the JSM Customer Request Type from a dedicated picker, the way JSM itself treats it, so tickets land in the right portal queue and route correctly from the start. * **Workflow-driven ticket creation.** Use **Create JSM ticket** as a workflow step, with field mapping and approval gating where needed. * **Custom field mapping.** Map Siit form fields and request attributes to your JSM custom fields. * **Audit trail.** Every JSM action triggered from Siit is recorded on the request timeline.
### When to use Jira vs. Jira Service Management Both integrations live in the Atlassian ecosystem, but they fit different jobs: * **Use Jira** when escalating to engineering, product, or platform teams who track work in Jira Software projects (bug fixes, feature requests, project-linked work). * **Use Jira Service Management** when escalating to specialist ITSM queues (network team, security ops, facilities, advanced IT) who manage incoming requests as JSM tickets. If both teams use Atlassian, you can connect both integrations and pick the right destination per request. ### How it works When a Siit request needs specialist attention managed in JSM: 1. From the request side panel, click **Escalate ticket** and pick **Jira Service Management**. 2. Choose the JSM service project, request type, and any required fields. Custom fields configured in **Settings → Integrations → Jira Service Management** appear automatically. 3. Submit. Siit creates the JSM ticket, links it back to the Siit request, and posts the link on both sides. 4. As the JSM ticket progresses, status updates flow back to Siit. Use these as workflow conditions — for example, "when the linked JSM ticket is Resolved, set the Siit request to Resolved." The same flow is available in workflows (as a **Create JSM ticket** action). ### What syncs from JSM Sync is set at the integration level and is fully bi-directional. In **Settings → Integrations → Jira Service Management → Settings**, you get one table per direction. Each row is an event, and you choose how Siit reacts. **From Siit to JSM** controls what happens on the JSM ticket when the Siit request changes: resolve on resolution, match the assignee, push notes, and push new messages, each opt-in or set to do nothing. **From JSM to Siit** controls what flows back to the request when the JSM ticket changes: resolve the request, match the assignee, import comments, and import notes. Every option is opt-in, and the choices are capability-aware: Siit only shows behaviors JSM can honor. This also prevents a private note from surfacing as a public comment where the provider has no private-comment concept.
### Custom field mapping Map Siit data to JSM custom fields so escalated tickets arrive with the right metadata — request ID, requester, service, priority, anything specialist teams need to triage quickly. Set this up in **Settings → Integrations → Jira Service Management → Field mapping**. For the full setup guide, see [Custom field mapping](https://help.siit.io/custom-field-mapping).
### Before you connect * A JSM admin (or Jira site admin) to authorize the connection. * A clear idea of which JSM service project(s) you want to escalate to. * Optional: a dedicated "Siit Integration" Jira user, so the integration survives admin turnover. ### Connect Jira Service Management 1. In Siit, go to **Settings → Integrations**, find **Jira Service Management** in the Ticketing section, and click **Connect**. 2. Sign in to your Atlassian site as an admin and approve the requested scopes. 3. Pick the JSM service project(s) you want available for escalation. 4. Configure default request type, priority, and field mapping. 5. Test by escalating a sample request from Siit to JSM. Need a more detailed walkthrough? Reach out to support via the in-app chat — the JSM setup follows the same Atlassian OAuth flow as our Jira integration ([Jira integration setup](https://help.siit.io/jira-integration) is a useful reference). ### After the connection * **Try the side panel.** From any request, click **Escalate ticket → Jira Service Management** and create a test ticket. * **Set up status sync rules.** Map JSM statuses to Siit's external ticket statuses (e.g., JSM "Resolved" → Siit "Resolved"). * **Configure field mapping.** Map your Siit fields to the JSM custom fields specialist teams rely on. * **Build your first workflow.** A common starter: "when tag = 'Network', auto-create a JSM ticket in the Network service project." ### Common workflows **Network team handoff.** *Trigger: Tag "network" added. Actions: Create JSM ticket in NETWORK service project → Notify requester with the JSM link.* **Security incident escalation.** *Trigger: Service = "Report security concern". Actions: Create JSM ticket in SEC service project → Set Siit priority to High → Post to #security-ops.* **Facilities request.** *Trigger: Service = "Office issue". Action: Create JSM ticket in FACILITIES service project, pre-filling the requester's office location from their profile.* **Auto-resolve on JSM completion.** *Trigger: Linked JSM ticket status = Resolved. Action: Set Siit request to Resolved → Notify requester.* ### Tips * **Use a dedicated service account** for the JSM connection so it survives individual admin turnover. * **Map JSM request types thoughtfully.** JSM request types matter for SLA and queue routing on the JSM side — pick the right default for each escalation path. * **Keep Siit as the employee surface.** Employees stay in Slack, Teams, or the Siit Portal. The JSM ticket is internal — only specialists need to see it. * **Use status sync to close the loop.** Mapping JSM "Resolved" to Siit "Resolved" keeps requesters informed without manual ticket updates. ### Help Center guides * [Jira integration setup](https://help.siit.io/jira-integration) — Atlassian setup walkthrough (also covers JSM) * [Jira fields consumed](https://help.siit.io/jira-fields-consumed) — full field reference (applies to JSM) * [Custom field mapping](https://help.siit.io/custom-field-mapping) — map Siit data to JSM custom fields ### Troubleshooting **"Authorization failed" on connect.** The admin signing in lacks Atlassian admin rights, or the site has restricted third-party app installs. Try with a site admin. **Service project missing from the destination picker.** The Siit Atlassian user lacks Browse Projects permission for that JSM project. Update permissions in JSM and re-sync. **Request type or Customer Request Type missing.** The integration only surfaces request types the connecting user can create. Check the user's JSM portal access for that service project. **A service project shows as unreachable.** The project was deleted or archived. Siit flags it in the collections list so escalations don't fail silently. **Custom field not appearing in mapping.** The field may be tied to a specific request type or screen scheme. Confirm the field is on the request type's create or edit screen, then re-run mapping. **A sync event isn't cascading.** Check the sync table in **Settings → Integrations → Jira Service Management → Settings**. Events set to "Do nothing" won't cascade, and behaviors JSM can't honor won't appear as options. # Zendesk Connect Zendesk to Siit to escalate requests into Zendesk tickets with one click.
Escalate Siit requests to Zendesk specialist groups with one click. Custom field mapping ensures every escalated ticket arrives with the right context, so your support team triages faster, not from scratch. ### What you get * **One-click escalation from any request.** Click **Escalate ticket** in the request side panel, pick a Zendesk group and ticket form, and a linked ticket is created with the Siit context pre-filled. * **Workflow-driven ticket creation.** Use **Create Zendesk ticket** as a workflow step, with field mapping and approval gating where needed. * **IT Agent native support.** `/zendesk create ticket` is available inside IT Agent playbooks, with optional approval. * **Custom field mapping.** Map Siit form fields and request attributes to your Zendesk custom fields, so escalated tickets land with the right context every time. * **Audit trail.** Every Zendesk action triggered from Siit is recorded on the request timeline. ### How it works When a Siit request needs to be handled in Zendesk: 1. From the request side panel, click **Escalate ticket** and pick **Zendesk**. 2. Choose the group, ticket form, priority, and any required fields. Custom fields configured in **Settings → Integrations → Zendesk** appear automatically. 3. Submit. Siit creates the Zendesk ticket, links it back to the Siit request, and posts the link on both sides. The same flow is available in workflows (as a **Create Zendesk ticket** action) and in IT Agent playbooks (via the `/zendesk create ticket` slash command). ### What syncs from Zendesk * **Tickets created from Siit** — every escalated ticket is tracked with its Zendesk ticket ID and link. * **Sync** is fully configurable and per-direction (`Settings → Integrations → Zendesk → Settings`): * **Resolution** — resolve on one side, close on the other (with status mapping). * **Assignee** — reassignments mirror across. * **Notes** — internal notes sync. * **Messages** — new messages sync. * **Links** — bidirectional links stay visible on both sides. ### Custom field mapping Map Siit data to Zendesk custom fields so escalated tickets arrive with the right metadata — request ID, requester, service, priority, anything specialist teams need to triage quickly. Set this up in **Settings → Integrations → Zendesk → Field mapping**. For the full setup guide, see [Custom field mapping](https://help.siit.io/custom-field-mapping). ### Before you connect * A Zendesk admin to authorize the connection. * A clear idea of which Zendesk group(s) and ticket form(s) you want to escalate to. * Optional: a dedicated "Siit Integration" Zendesk agent, so the integration survives admin turnover. ### Connect Zendesk 1. In Siit, go to **Settings → Integrations**, find **Zendesk** in the Ticketing section, and click **Connect**. 2. Enter your Zendesk subdomain (the `yourcompany` part of `yourcompany.zendesk.com`). 3. Sign in as a Zendesk admin and approve the requested scopes. 4. Pick the group(s) and ticket form(s) you want available for escalation. 5. Configure default ticket form, priority, and field mapping. 6. Test by escalating a sample request from Siit to Zendesk. Need a more detailed walkthrough? Reach out to support via the in-app chat. ### After the connection * **Try the side panel.** From any request, click **Escalate ticket → Zendesk** and create a test ticket. * **Configure field mapping.** Map your Siit fields to the Zendesk custom fields specialist teams rely on. * **Build your first workflow.** A common starter: "when service = 'Customer escalation', auto-create a Zendesk ticket in the support group." ### Common workflows **Customer support escalation.** *Trigger: Service = "Customer escalation". Actions: Create Zendesk ticket in the support group → Set Siit priority to High → DM requester with the Zendesk link.* **Specialist team handoff.** *Trigger: Tag "advanced-support" added. Actions: Manager approval → Create Zendesk ticket → Notify requester.* **Dedicated helpdesk routing.** *Trigger: Requester's department = "External". Action: Create Zendesk ticket in the external-support group, pre-filling the requester's company from their profile.* ### IT Agent integration Inside an IT Agent playbook, use `/zendesk create ticket` to let the agent escalate autonomously — with approval gating on the action when you want a human in the loop. A common playbook: an employee reports a complex issue in Slack → IT Agent gathers context → requests manager approval → creates a Zendesk ticket → posts the link back to the employee. See IT Agent for playbook examples. ### Tips * **Use a dedicated service account** for the Zendesk connection so it survives individual admin turnover. * **Start with one group and one ticket form.** Map fields and test thoroughly with one path before expanding. * **Keep Siit as the employee surface.** Employees stay in Slack, Teams, or the Siit Portal. The Zendesk ticket is internal — only specialists need to see it. * **Track resolution manually for now.** Without bi-directional status sync, you'll need to close the Siit request manually (or via a workflow triggered by something else) when the Zendesk ticket is resolved. ### Help Center guides * [Custom field mapping](https://help.siit.io/custom-field-mapping) — map Siit data to Zendesk custom fields ### Troubleshooting **"Authorization failed" on connect.** The admin signing in lacks Zendesk admin rights, or the Zendesk account has restricted third-party app installs. Try with an admin who has full access. **Group missing from the destination picker.** The Siit Zendesk user lacks access to that group. Update group membership in Zendesk and re-sync. **Custom field not appearing in mapping.** The field may be tied to a specific ticket form or set as inactive. Confirm the field is active and on the ticket form, then re-run the mapping step. **"Ticket created" but no link in Siit.** The Zendesk ticket was created but the back-link save failed. Open the request timeline — the Zendesk ticket ID is logged. Manually re-link if needed. # Linear Connect Linear to Siit to escalate requests into Linear issues with one click, keep statuses in sync between both tools, and automate Linear issue creation from any workflow.
### What you get * **One-click escalation from any request.** Click **Escalate ticket** in the request side panel, pick a Linear team and project, and a linked issue is created with the Siit context pre-filled. * **Bi-directional status sync.** Status changes on the Linear issue update the Siit request's external status field automatically — and the link stays visible on both sides. * **IT Agent native support.** `/linear create ticket` is available inside IT Agent playbooks, with optional approval. * **Workflow-driven issue creation.** Use **Create Linear issue** as a workflow step, with approval gating where needed. * **Audit trail.** Every Linear action triggered from Siit is recorded on the request timeline. ### How it works When a Siit request needs engineering or product work tracked in Linear: 1. From the request side panel, click **Escalate ticket** and pick **Linear**. 2. Choose the team, project (optional), labels, and priority. Fill in the title and description. 3. Submit. Siit creates the Linear issue, links it back to the Siit request, and posts the link on both sides. 4. As the Linear issue progresses, status updates flow back to Siit. Use these as workflow conditions — for example, "when the linked Linear issue is Done, set the Siit request to Resolved." The same flow is available in workflows (as a **Create Linear issue** action). ### What syncs from Linear * **Issues created from Siit** — every escalated ticket is tracked with its Linear identifier, team, project, and current status. * **Sync** is fully configurable and per-direction (`Settings → Integrations → Linear → Settings`): * **Resolution** — resolve on one side, close on the other (with status mapping). * **Assignee** — reassignments mirror across. * **Notes** — internal notes sync. * **Messages** — new messages sync. * **Links** — bidirectional links stay visible on both sides. ### Custom field mapping > **Coming soon.** Custom field mapping for Linear is on our roadmap. For now, you can set the title, description, team, project, labels, and priority when escalating to Linear. To track which fields are exposed, reach out via the in-app chat. ### Before you connect * A Linear admin (Workspace Admin) to authorize the connection. * A clear idea of which Linear team(s) you want to escalate to. Start with one, then expand. * Optional: a dedicated "Siit Integration" Linear user, so the integration survives admin turnover. ### Connect Linear 1. In Siit, go to **Settings → Integrations**, find **Linear** in the Ticketing section, and click **Connect**. 2. Sign in to your Linear workspace as an admin and approve the requested scopes. 3. Pick the Linear team(s) you want available for escalation. 4. Configure the default team, project, and priority for escalations. 5. Test by escalating a sample request from Siit to Linear. Need a more detailed walkthrough? Reach out to support via the in-app chat. ### After the connection * **Try the side panel.** From any request, click **Escalate ticket → Linear** and create a test issue. * **Set up status sync rules.** In **Settings → Integrations → Linear**, map Linear statuses to Siit's external ticket statuses (e.g., Linear "Done" → Siit "Resolved"). * **Build your first workflow.** A common starter: "when service = 'New integration', auto-create a Linear issue in the platform team's backlog and notify the requester." ### Common workflows **New integration request.** *Trigger: Service = "New integration request". Actions: Manager approval → Create Linear issue in the platform team → DM requester with the Linear link.* **Bug report auto-escalation.** *Trigger: Service = "App bug report". Actions: Create Linear issue in the engineering team → Set Siit status to Waiting → Notify requester.* **Auto-resolve on Linear completion.** *Trigger: Linked Linear issue status = Done. Actions: Set Siit request to Resolved → Notify requester.* ### IT Agent integration Inside an IT Agent playbook, use `/linear create ticket` to let the agent escalate autonomously — with approval gating on the action when you want a human in the loop. A common playbook: an employee reports a complex issue in Slack → IT Agent gathers context → requests manager approval → creates a Linear issue → posts the link back to the employee. See IT Agent for playbook examples. ### Tips * **Use a dedicated service account** for the Linear connection so it survives individual admin turnover. * **Start with one team.** It's tempting to connect every Linear team — but mapping statuses for one well-used team first is faster and lower-risk. * **Keep Siit as the employee surface.** Employees shouldn't need a Linear account to track their request. The Siit request stays their canonical view; the linked Linear issue is internal. * **Use status sync to close the loop.** Mapping Linear "Done" to Siit "Resolved" keeps requesters informed without anyone manually updating the Siit ticket. ### Troubleshooting **"Authorization failed" on connect.** The admin signing in lacks Linear Workspace Admin rights. Try with a Workspace Admin. **Team missing from the destination picker.** The Siit Linear user lacks access to that team. Update team membership in Linear and re-sync. **Status sync isn't updating Siit.** Check the status mapping in **Settings → Integrations → Linear → Status sync**. If a Linear status isn't mapped, transitions through it won't update Siit. **"Issue created" but no link in Siit.** The Linear issue was created but the back-link save failed. Open the request timeline — the Linear issue ID is logged. Manually re-link if needed, then check Siit's connection token validity. # Freshservice Connect Freshservice to Siit to escalate requests into Freshservice tickets with one click. The Freshservice integration is the right choice when specialist teams
### What you get * **One-click escalation from any request.** Click **Escalate ticket** in the request side panel, pick a Freshservice group and ticket type, and a linked ticket is created with the Siit context pre-filled. * **IT Agent native support.** `/Freshservice create ticket` is available inside IT Agent playbooks, with optional approval. * **Workflow-driven ticket creation.** Use **Create Freshservice ticket** as a workflow step, with approval gating where needed. * **Audit trail.** Every Freshservice action triggered from Siit is recorded on the request timeline. ### How it works When a Siit request needs to be handled by a specialist team in Freshservice: 1. From the request side panel, click **Escalate ticket** and pick **Freshservice**. 2. Choose the group, ticket type, priority, and required fields. Fill in the subject and description. 3. Submit. Siit creates the Freshservice ticket, links it back to the Siit request, and posts the link on both sides. The same flow is available in workflows (as a **Create Freshservice ticket** action). ### What syncs from Freshservice * **Tickets created from Siit** — every escalated ticket is tracked with its Freshservice ticket ID and link. * **Sync** is fully configurable and per-direction (`Settings → Integrations → Freshservice → Settings`): * **Resolution** — resolve on one side, close on the other (with status mapping). * **Assignee** — reassignments mirror across. * **Notes** — internal notes sync. * **Messages** — new messages sync. * **Links** — bidirectional links stay visible on both sides. ### Custom field mapping Custom field mapping for Freshservice is available in Siit ### Before you connect * A Freshservice admin to generate an API key. * A clear idea of which Freshservice group(s) and ticket type(s) you want to escalate to. * Optional: a dedicated "Siit Integration" Freshservice agent, so the integration survives admin turnover. ### Connect Freshservice 1. In Freshservice, generate an API key for the agent Siit will use: * In Freshservice, click your profile avatar → **Profile settings**. * Copy the API key shown on the right. 2. In Siit, go to **Settings → Integrations**, find **Freshservice** in the Ticketing section, and click **Connect**. 3. Enter your Freshservice domain (e.g., `yourcompany.freshservice.com`) and the API key. 4. Click **Authorize**. Siit verifies the connection. 5. Pick the group(s) and ticket type(s) you want available for escalation. 6. Test by escalating a sample request from Siit to Freshservice. Need a more detailed walkthrough? Reach out to support via the in-app chat. ### After the connection * **Try the side panel.** From any request, click **Escalate ticket → Freshservice** and create a test ticket. * **Configure default routing.** In **Settings → Integrations → Freshservice**, set the default group and ticket type for escalations. * **Build your first workflow.** A common starter: "when tag = 'Network', auto-create a Freshservice ticket in the network team queue." ### Common workflows **Network team handoff.** *Trigger: Tag "network" added. Actions: Create Freshservice ticket in the network group → Notify requester with the Freshservice link.* **Security incident escalation.** *Trigger: Service = "Report security concern". Actions: Create Freshservice ticket in the security group → Set Siit priority to High → Post to #security-ops.* **Specialist handoff.** *Trigger: Request assigned to "Advanced IT" inbox. Action: Create Freshservice ticket in the advanced-IT queue → Note on Siit request with the ticket URL.* ### IT Agent integration Inside an IT Agent playbook, use `/Freshservice create ticket` to let the agent escalate autonomously — with approval gating on the action when you want a human in the loop. A common playbook: an employee reports a complex issue in Slack → IT Agent gathers context → requests manager approval → creates a Freshservice ticket → posts the link back to the employee. See IT Agent for playbook examples. ### Tips * **Use a dedicated service account** for the Freshservice API key so the integration survives individual admin turnover. * **Start with one group and ticket type.** Test the escalation path thoroughly before expanding. * **Keep Siit as the employee surface.** Employees stay in Slack, Teams, or the Siit Portal. The Freshservice ticket is internal — only specialists need to see it. * **Track resolution manually for now.** Without bi-directional status sync, you'll need to close the Siit request manually (or via a workflow triggered by something else) when the Freshservice ticket is resolved. ### Troubleshooting **"Invalid credentials" on connect.** The API key is wrong, has been regenerated, or the agent it belongs to has been deactivated. Generate a fresh API key in Freshservice and update Siit. **Group missing from the destination picker.** The Siit Freshservice agent lacks access to that group. Update group membership in Freshservice and re-sync. **Ticket type missing.** The integration only surfaces ticket types the connecting agent can create. Check the agent's permissions for that group. **"Ticket created" but no link in Siit.** The Freshservice ticket was created but the back-link save failed. Open the request timeline — the Freshservice ticket ID is logged. Manually re-link if needed. # Freshdesk Connect Freshdesk to Siit to escalate requests into Freshdesk tickets with one click. The Freshdesk integration is the right choice when customer support teams already manage their work in Freshdesk. ### What you get * **One-click escalation from any request.** Click **Escalate ticket** in the request side panel, pick a Freshdesk group and ticket type, and a linked ticket is created with the Siit context pre-filled. * **Workflow-driven ticket creation.** Use **Create Freshdesk ticket** as a workflow step, with approval gating where needed. * **Audit trail.** Every Freshdesk action triggered from Siit is recorded on the request timeline. ### How it works 1. From the request side panel, click **Escalate ticket** and pick **Freshdesk**. 2. Choose the group, ticket type, priority, and required fields. Fill in the subject and description. 3. Submit. Siit creates the Freshdesk ticket, links it back to the Siit request, and posts the link on both sides. The same flow is available in workflows (as a **Create Freshdesk ticket** action). ### What syncs from Freshdesk * **Tickets created from Siit** — every escalated ticket is tracked with its Freshdesk ticket ID and link. * **Sync** is fully configurable and per-direction (`Settings → Integrations → Freshdesk → Settings`): * **Resolution** — resolve on one side, close on the other (with status mapping). * **Assignee** — reassignments mirror across. * **Notes** — internal notes sync. * **Messages** — new messages sync. * **Links** — bidirectional links stay visible on both sides. ### Custom field mapping > **Coming soon.** Custom field mapping for Freshdesk is on our roadmap. For now, you can set the standard ticket fields when escalating. To track which fields are exposed, reach out via the in-app chat. ### Connect Freshdesk 1. In Freshdesk, generate an API key for the agent Siit will use (Profile settings → API key). 2. In Siit, go to **Settings → Integrations**, find **Freshdesk** in the Ticketing section, and click **Connect**. 3. Enter your Freshdesk domain (e.g., `yourcompany.freshdesk.com`) and the API key. 4. Click **Authorize**. Pick the group(s) and ticket type(s) available for escalation. 5. Test by escalating a sample request from Siit to Freshdesk. Need a more detailed walkthrough? Reach out to support via the in-app chat. ### Common workflows **Customer support escalation.** *Trigger: Service = "Customer escalation". Actions: Create Freshdesk ticket in the support group → Notify requester with the Freshdesk link.* **Tag-based handoff.** *Trigger: Tag "external-support" added. Actions: Manager approval → Create Freshdesk ticket → Notify requester.* ### Troubleshooting **"Invalid credentials" on connect.** The API key is wrong or has been regenerated. Generate a fresh API key in Freshdesk and update Siit. **Group missing from the destination picker.** The Siit Freshdesk agent lacks access to that group. Update group membership in Freshdesk and re-sync. **"Ticket created" but no link in Siit.** The Freshdesk ticket was created but the back-link save failed. Open the request timeline — the Freshdesk ticket ID is logged. Manually re-link if needed. # ServiceNow Connect ServiceNow to Siit to escalate requests into ServiceNow records with one click. ServiceNow is the right choice when enterprise IT, security, or facilities teams manage their work in ServiceNow ### What you get * **One-click escalation from any request.** Click **Escalate ticket** in the request side panel, pick a ServiceNow table and assignment group, and a linked record is created with the Siit context pre-filled. * **Workflow-driven ticket creation.** Use **Create ServiceNow ticket** as a workflow step, with approval gating where needed. * **Audit trail.** Every ServiceNow action triggered from Siit is recorded on the request timeline. ### How it works 1. From the request side panel, click **Escalate ticket** and pick **ServiceNow**. 2. Choose the table (Incident, Request, Change, etc.), assignment group, priority, and required fields. Fill in the short description and description. 3. Submit. Siit creates the ServiceNow record, links it back to the Siit request, and posts the link on both sides. The same flow is available in workflows (as a **Create ServiceNow ticket** action). ### What syncs from ServiceNow * **Records created from Siit** — every escalated ticket is tracked with its ServiceNow number, table, and link. * **Links** — preserved between the Siit request and the ServiceNow record, visible on both sides. > **Note** — bi-directional status sync is not currently available for ServiceNow. Track resolution either through the ServiceNow link on the request or by manually closing the Siit request when work is done. ### Custom field mapping > **Coming soon.** Custom field mapping for ServiceNow is on our roadmap. For now, you can set the standard record fields when escalating. To track which fields are exposed, reach out via the in-app chat. ### Connect ServiceNow ServiceNow setup varies by tenant configuration. You'll need: * A ServiceNow admin to create an integration user with REST API access to the relevant tables (Incident, Request, etc.). * Your ServiceNow instance URL. For the recommended setup for your tenant, reach out to support via the in-app chat — we'll work with you to scope and configure the connection correctly. 1. In Siit, go to **Settings → Integrations**, find **ServiceNow** in the Ticketing section, and click **Connect**. 2. Enter your ServiceNow instance URL and integration user credentials. 3. Pick the table(s) and assignment group(s) available for escalation. 4. Test by escalating a sample request from Siit to ServiceNow. ### Common workflows **Incident escalation.** *Trigger: Tag "incident" added. Actions: Create ServiceNow Incident in the IT Ops group → Set Siit priority to High → Post to #it-incidents.* **Change request handoff.** *Trigger: Service = "Infrastructure change". Actions: Manager approval → Create ServiceNow Change record → Notify requester.* ### Troubleshooting **"401 Unauthorized" on connect.** The integration user password is wrong or the account has been locked. Reset and update Siit. **Tables or groups missing.** The integration user lacks REST API access to that table or assignment group. Ask your ServiceNow admin to extend the user's access. **"Record created" but no link in Siit.** The ServiceNow record was created but the back-link save failed. Open the request timeline — the ServiceNow number is logged. Manually re-link if needed. # GitHub Connect GitHub to Siit to escalate requests into GitHub issues with one click. GitHub is the right choice for handing off engineering work. ### What you get * **One-click escalation from any request.** Click **Escalate ticket** in the request side panel, pick a GitHub repository and labels, and a linked issue is created with the Siit context pre-filled. * **Workflow-driven issue creation.** Use **Create GitHub issue** as a workflow step, with approval gating where needed. * **Audit trail.** Every GitHub action triggered from Siit is recorded on the request timeline. ### How it works 1. From the request side panel, click **Escalate ticket** and pick **GitHub**. 2. Choose the repository, labels, assignees, and milestone (optional). Fill in the title and description. 3. Submit. Siit creates the GitHub issue, links it back to the Siit request, and posts the link on both sides. The same flow is available in workflows (as a **Create GitHub issue** action). ### What syncs from GitHub * **Issues created from Siit** — every escalated ticket is tracked with its GitHub issue number, repository, and link. * **Links** — preserved between the Siit request and the GitHub issue, visible on both sides. > **Note** — bi-directional status sync is not currently available for GitHub. Track resolution either through the GitHub link on the request or by manually closing the Siit request when the issue is closed. ### Custom field mapping > **Coming soon.** Custom field mapping for GitHub is on our roadmap. For now, you can set the standard issue fields (title, description, labels, assignees, milestone) when escalating. To track which fields are exposed, reach out via the in-app chat. ### Connect GitHub 1. In Siit, go to **Settings → Integrations**, find **GitHub** in the Ticketing section, and click **Connect**. 2. Sign in to GitHub as an admin and approve the requested scopes. 3. Pick the organization and repository(ies) available for escalation. 4. Test by escalating a sample request from Siit to GitHub. Need a more detailed walkthrough? Reach out to support via the in-app chat. ### Common workflows **Bug report auto-escalation.** *Trigger: Service = "App bug report". Actions: Create GitHub issue in the engineering repo → Add label "bug" → Notify requester.* **Infrastructure request.** *Trigger: Tag "infra" added. Actions: Manager approval → Create GitHub issue in the infra repo → Notify requester.* ### Troubleshooting **"Authorization failed" on connect.** The admin signing in lacks org admin rights, or the org restricts third-party app installs. Try with an org owner. **Repository missing from the destination picker.** The Siit GitHub user lacks access to that repository. Update repo permissions in GitHub and re-sync. **"Issue created" but no link in Siit.** The GitHub issue was created but the back-link save failed. Open the request timeline — the GitHub issue number is logged. Manually re-link if needed. # GitLab Connect GitLab to Siit to escalate requests into GitLab issues with one click. GitLab is the right choice for handing off engineering, DevOps, and infrastructure work to teams that track their work. ### What you get * **One-click escalation from any request.** Click **Escalate ticket** in the request side panel, pick a GitLab project and labels, and a linked issue is created with the Siit context pre-filled. * **Workflow-driven issue creation.** Use **Create GitLab issue** as a workflow step, with approval gating where needed. * **Audit trail.** Every GitLab action triggered from Siit is recorded on the request timeline. ### How it works 1. From the request side panel, click **Escalate ticket** and pick **GitLab**. 2. Choose the project, labels, assignees, and milestone (optional). Fill in the title and description. 3. Submit. Siit creates the GitLab issue, links it back to the Siit request, and posts the link on both sides. The same flow is available in workflows (as a **Create GitLab issue** action). ### What syncs from GitLab * **Issues created from Siit** — every escalated ticket is tracked with its GitLab issue ID, project, and link. * **Links** — preserved between the Siit request and the GitLab issue, visible on both sides. > **Note** — bi-directional status sync is not currently available for GitLab. Track resolution either through the GitLab link on the request or by manually closing the Siit request when the issue is closed. ### Custom field mapping > **Coming soon.** Custom field mapping for GitLab is on our roadmap. For now, you can set the standard issue fields (title, description, labels, assignees, milestone) when escalating. To track which fields are exposed, reach out via the in-app chat. ### Connect GitLab 1. In GitLab, generate a Personal Access Token (or Group Access Token) with `api` and `read_user` scopes. 2. In Siit, go to **Settings → Integrations**, find **GitLab** in the Ticketing section, and click **Connect**. 3. Enter your GitLab URL (Cloud or self-hosted) and paste the token, then click **Authorize**. 4. Pick the project(s) available for escalation. 5. Test by escalating a sample request from Siit to GitLab. Need a more detailed walkthrough? Reach out to support via the in-app chat. ### Common workflows **Bug report auto-escalation.** *Trigger: Service = "App bug report". Actions: Create GitLab issue in the engineering project → Add label "bug" → Notify requester.* **DevOps request.** *Trigger: Tag "devops" added. Actions: Manager approval → Create GitLab issue in the infra project → Notify requester.* ### Troubleshooting **"Invalid token" on connect.** The token has been revoked or lacks the required scopes. Generate a new one with `api` and `read_user` scopes. **Project missing from the destination picker.** The token's user lacks access to that project. Update project membership in GitLab and re-sync. **"Issue created" but no link in Siit.** The GitLab issue was created but the back-link save failed. Open the request timeline — the GitLab issue ID is logged. Manually re-link if needed. # ClickUp Connect ClickUp to Siit to escalate requests into ClickUp tasks with one click. ClickUp is the right choice when ops, project, or product teams already manage their work in ClickUp. ### What you get * **One-click escalation from any request.** Click **Escalate ticket** in the request side panel, pick a ClickUp space, list, and assignee, and a linked task is created with the Siit context pre-filled. * **Workflow-driven task creation.** Use **Create ClickUp task** as a workflow step, with approval gating where needed. * **Audit trail.** Every ClickUp action triggered from Siit is recorded on the request timeline. ### How it works 1. From the request side panel, click **Escalate ticket** and pick **ClickUp**. 2. Choose the space, list, assignee, priority, and due date. Fill in the task name and description. 3. Submit. Siit creates the ClickUp task, links it back to the Siit request, and posts the link on both sides. The same flow is available in workflows (as a **Create ClickUp task** action). ### What syncs from ClickUp * **Tasks created from Siit** — every escalated ticket is tracked with its ClickUp task ID and link. * **Links** — preserved between the Siit request and the ClickUp task, visible on both sides. > **Note** — bi-directional status sync is not currently available for ClickUp. Track completion either through the ClickUp link on the request or by manually closing the Siit request when work is done. ### Custom field mapping > **Coming soon.** Custom field mapping for ClickUp is on our roadmap. For now, you can set the standard task fields when escalating. To track which fields are exposed, reach out via the in-app chat. ### Connect ClickUp 1. In Siit, go to **Settings → Integrations**, find **ClickUp** in the Ticketing section, and click **Connect**. 2. Sign in to ClickUp as an admin and approve the requested scopes. 3. Pick the workspace, space(s), and list(s) available for escalation. 4. Test by escalating a sample request from Siit to ClickUp. Need a more detailed walkthrough? Reach out to support via the in-app chat. ### Common workflows **Project request handoff.** *Trigger: Service = "Project request". Actions: Create ClickUp task in the project list → Assign to the project lead → Notify requester.* **Tag-based routing.** *Trigger: Tag "ops-task" added. Actions: Manager approval → Create ClickUp task in the ops list → Notify requester.* ### Troubleshooting **"Authorization failed" on connect.** The admin signing in lacks ClickUp workspace admin rights. Try with a workspace owner. **List missing from the destination picker.** The Siit ClickUp user lacks access to that list. Update list permissions in ClickUp and re-sync. **"Task created" but no link in Siit.** The ClickUp task was created but the back-link save failed. Open the request timeline — the ClickUp task ID is logged. Manually re-link if needed. # Trello Connect Trello to Siit to escalate requests into Trello cards with one click. Trello is the right choice when ops, project, or marketing teams already manage their work on Trello boards. ### What you get * **One-click escalation from any request.** Click **Escalate ticket** in the request side panel, pick a Trello board and list, and a linked card is created with the Siit context pre-filled. * **Workflow-driven card creation.** Use **Create Trello card** as a workflow step, with approval gating where needed. * **Audit trail.** Every Trello action triggered from Siit is recorded on the request timeline. ### How it works 1. From the request side panel, click **Escalate ticket** and pick **Trello**. 2. Choose the board, list, members, labels, and due date. Fill in the card name and description. 3. Submit. Siit creates the Trello card, links it back to the Siit request, and posts the link on both sides. The same flow is available in workflows (as a **Create Trello card** action). ### What syncs from Trello * **Cards created from Siit** — every escalated ticket is tracked with its Trello card ID and link. * **Sync** is fully configurable and per-direction (`Settings → Integrations → Trello → Settings`): * **Resolution** — resolve on one side, close on the other (with status mapping). * **Assignee** — reassignments mirror across. * **Notes** — internal notes sync. * **Messages** — new messages sync. * **Links** — bidirectional links stay visible on both sides. ### Custom field mapping > **Coming soon.** Custom field mapping for Trello is on our roadmap. For now, you can set the standard card fields when escalating. To track which fields are exposed, reach out via the in-app chat. ### Connect Trello 1. In Siit, go to **Settings → Integrations**, find **Trello** in the Ticketing section, and click **Connect**. 2. Sign in to Trello as an admin and approve the requested scopes. 3. Pick the workspace and board(s) available for escalation. 4. Test by escalating a sample request from Siit to Trello. Need a more detailed walkthrough? Reach out to support via the in-app chat. ### Common workflows **Marketing request handoff.** *Trigger: Service = "Marketing request". Actions: Create Trello card on the marketing board → Assign to the campaign lead → Notify requester.* **Tag-based routing.** *Trigger: Tag "ops-task" added. Actions: Manager approval → Create Trello card on the ops board → Notify requester.* ### Troubleshooting **"Authorization failed" on connect.** The admin signing in lacks workspace admin rights. Try with a Trello workspace admin. **Board missing from the destination picker.** The Siit Trello user lacks access to that board. Update board membership in Trello and re-sync. **"Card created" but no link in Siit.** The Trello card was created but the back-link save failed. Open the request timeline — the Trello card ID is logged. Manually re-link if needed. # Asana Connect Asana to Siit to escalate requests into Asana tasks with one click. Asana is the right choice when ops, marketing, or project teams already manage their work in Asana and you want clean handof ### What you get * **One-click escalation from any request.** Click **Escalate ticket** in the request side panel, pick an Asana workspace, project, and assignee, and a linked task is created with the Siit context pre-filled. * **Workflow-driven task creation.** Use **Create Asana task** as a workflow step, with approval gating where needed. * **Audit trail.** Every Asana action triggered from Siit is recorded on the request timeline. ### How it works 1. From the request side panel, click **Escalate ticket** and pick **Asana**. 2. Choose the workspace, project, assignee, and due date. Fill in the task name and description. 3. Submit. Siit creates the Asana task, links it back to the Siit request, and posts the link on both sides. The same flow is available in workflows (as a **Create Asana task** action). ### What syncs from Asana * **Tasks created from Siit** — every escalated ticket is tracked with its Asana task ID and link. * **Links** — preserved between the Siit request and the Asana task, visible on both sides. > **Note** — bi-directional status sync is not currently available for Asana. Track completion either through the Asana link on the request or by manually closing the Siit request when work is done. ### Custom field mapping > **Coming soon.** Custom field mapping for Asana is on our roadmap. For now, you can set the standard task fields when escalating. To track which fields are exposed, reach out via the in-app chat. ### Connect Asana 1. In Siit, go to **Settings → Integrations**, find **Asana** in the Ticketing section, and click **Connect**. 2. Sign in to Asana as an admin and approve the requested scopes. 3. Pick the workspace(s) and project(s) available for escalation. 4. Test by escalating a sample request from Siit to Asana. Need a more detailed walkthrough? Reach out to support via the in-app chat. ### Common workflows **Marketing request handoff.** *Trigger: Service = "Marketing asset request". Actions: Create Asana task in the marketing project → Assign to the design lead → Notify requester.* **Ops project work.** *Trigger: Tag "ops-project" added. Actions: Manager approval → Create Asana task in the ops project → Notify requester.* ### Troubleshooting **"Authorization failed" on connect.** The admin signing in lacks Asana admin rights. Try with an admin who has full workspace access. **Project missing from the destination picker.** The Siit Asana user lacks access to that project. Update project membership in Asana and re-sync. **"Task created" but no link in Siit.** The Asana task was created but the back-link save failed. Open the request timeline — the Asana task ID is logged. Manually re-link if needed. # Kustomer Connect Kustomer to Siit to escalate requests into Kustomer conversations with one click. Kustomer is the right choice when customer-facing teams already manage their work in Kustomer. ### What you get * **One-click escalation from any request.** Click **Escalate ticket** in the request side panel, pick a Kustomer queue or team, and a linked conversation is created with the Siit context pre-filled. * **Workflow-driven creation.** Use **Create Kustomer conversation** as a workflow step, with approval gating where needed. * **Audit trail.** Every Kustomer action triggered from Siit is recorded on the request timeline. ### How it works 1. From the request side panel, click **Escalate ticket** and pick **Kustomer**. 2. Choose the queue or team, channel, and priority. Fill in the subject and message. 3. Submit. Siit creates the Kustomer conversation, links it back to the Siit request, and posts the link on both sides. The same flow is available in workflows (as a **Create Kustomer conversation** action). ### What syncs from Kustomer * **Conversations created from Siit** — every escalated ticket is tracked with its Kustomer conversation ID and link. * **Links** — preserved between the Siit request and the Kustomer conversation, visible on both sides. > **Note** — bi-directional status sync is not currently available for Kustomer. Track resolution either through the Kustomer link on the request or by manually closing the Siit request when work is done. ### Custom field mapping > **Coming soon.** Custom field mapping for Kustomer is on our roadmap. For now, you can set the standard conversation fields when escalating. To track which fields are exposed, reach out via the in-app chat. ### Connect Kustomer 1. In Kustomer, generate an API key with read/write access to conversations. 2. In Siit, go to **Settings → Integrations**, find **Kustomer** in the Ticketing section, and click **Connect**. 3. Paste the API key and your Kustomer org identifier, then click **Authorize**. 4. Pick the queue(s) and team(s) available for escalation. 5. Test by escalating a sample request from Siit to Kustomer. Need a more detailed walkthrough? Reach out to support via the in-app chat. ### Common workflows **Customer escalation.** *Trigger: Service = "Customer escalation". Actions: Create Kustomer conversation in the support queue → Set Siit priority to High → Notify requester.* **Specialist handoff.** *Trigger: Tag "vip-customer" added. Actions: Manager approval → Create Kustomer conversation in the VIP queue → Notify requester.* ### Troubleshooting **"Invalid credentials" on connect.** The API key has been revoked or lacks the required scopes. Generate a new one and update Siit. **Queue missing from the destination picker.** The Siit Kustomer user lacks access to that queue. Update access in Kustomer and re-sync. **"Conversation created" but no link in Siit.** The Kustomer conversation was created but the back-link save failed. Open the request timeline — the Kustomer conversation ID is logged. Manually re-link if needed. # Intercom Connect Intercom to Siit to escalate requests into Intercom conversations or tickets with one click. Intercom is the right choice when customer-facing teams already manage their work in Intercom. ### What you get * **One-click escalation from any request.** Click **Escalate ticket** in the request side panel, pick a destination, and a linked conversation or ticket is created with the Siit context pre-filled. * **Workflow-driven creation.** Use **Create Intercom ticket** as a workflow step, with approval gating where needed. * **Audit trail.** Every Intercom action triggered from Siit is recorded on the request timeline. ### How it works 1. From the request side panel, click **Escalate ticket** and pick **Intercom**. 2. Choose the team or assignee, ticket type, and priority. Fill in the subject and message. 3. Submit. Siit creates the Intercom ticket, links it back to the Siit request, and posts the link on both sides. The same flow is available in workflows (as a **Create Intercom ticket** action). ### What syncs from Intercom * **Tickets created from Siit** — every escalated ticket is tracked with its Intercom ID and link. * **Sync** is fully configurable and per-direction (`Settings → Integrations → Intercom → Settings`): * **Resolution** — resolve on one side, close on the other (with status mapping). * **Assignee** — reassignments mirror across. * **Notes** — internal notes sync. * **Messages** — new messages sync. * **Links** — bidirectional links stay visible on both sides. ### Custom field mapping > **Coming soon.** Custom field mapping for Intercom is on our roadmap. For now, you can set the standard ticket fields when escalating. To track which fields are exposed, reach out via the in-app chat. ### Connect Intercom 1. In Siit, go to **Settings → Integrations**, find **Intercom** in the Ticketing section, and click **Connect**. 2. Sign in to Intercom as an admin and approve the requested scopes. 3. Pick the team(s) available for escalation. 4. Test by escalating a sample request from Siit to Intercom. Need a more detailed walkthrough? Reach out to support via the in-app chat. ### Common workflows **Customer issue escalation.** *Trigger: Service = "Customer issue". Actions: Create Intercom ticket in the customer success team → Set Siit priority to High → Notify requester.* **Specialist handoff.** *Trigger: Tag "customer-support" added. Actions: Manager approval → Create Intercom ticket → Notify requester.* ### Troubleshooting **"Authorization failed" on connect.** The admin signing in lacks Intercom admin rights. Try with a workspace admin. **Team missing from the destination picker.** The Siit Intercom user lacks access to that team. Update team membership in Intercom and re-sync. **"Ticket created" but no link in Siit.** The Intercom ticket was created but the back-link save failed. Open the request timeline — the Intercom ID is logged. Manually re-link if needed. # Salesforce Service Cloud Connect Salesforce Service Cloud to Siit to escalate requests into Salesforce cases with one click. Service Cloud is the right choice when customer-facing teams already manage their work in Salesforce ### What you get * **One-click escalation from any request.** Click **Escalate ticket** in the request side panel, pick a Salesforce queue and case type, and a linked case is created with the Siit context pre-filled. * **Workflow-driven case creation.** Use **Create Salesforce case** as a workflow step, with approval gating where needed. * **Audit trail.** Every Salesforce action triggered from Siit is recorded on the request timeline. ### How it works 1. From the request side panel, click **Escalate ticket** and pick **Salesforce Service Cloud**. 2. Choose the queue or owner, case record type, priority, and required fields. Fill in the subject and description. 3. Submit. Siit creates the Salesforce case, links it back to the Siit request, and posts the link on both sides. The same flow is available in workflows (as a **Create Salesforce case** action). ### What syncs from Salesforce Service Cloud * **Cases created from Siit** — every escalated ticket is tracked with its Salesforce case number, record type, and link. * **Links** — preserved between the Siit request and the Salesforce case, visible on both sides. > **Note** — bi-directional status sync is not currently available for Salesforce Service Cloud. Track resolution either through the Salesforce link on the request or by manually closing the Siit request when work is done. ### Custom field mapping > **Coming soon.** Custom field mapping for Salesforce Service Cloud is on our roadmap. For now, you can set the standard case fields when escalating. To track which fields are exposed, reach out via the in-app chat. ### Connect Salesforce Service Cloud Salesforce setup varies by org configuration. You'll need: * A Salesforce admin to authorize the connection or create an integration user with API access to the Case object. * Your Salesforce instance URL. For the recommended setup for your org, reach out to support via the in-app chat — we'll work with you to scope and configure the connection correctly. 1. In Siit, go to **Settings → Integrations**, find **Salesforce Service Cloud** in the Ticketing section, and click **Connect**. 2. Sign in to Salesforce as an admin and approve the requested scopes. 3. Pick the queue(s) and case record type(s) available for escalation. 4. Test by escalating a sample request from Siit to Salesforce. ### Common workflows **Customer escalation.** \*Trigger: Service = "Customer escalation". Actions: Create Salesforce case in the support queue → Set Siit priority t # Zoho Desk Connect Zoho Desk to Siit to escalate requests into Zoho Desk tickets with one click. Zoho Desk is the right choice when customer support or specialist teams already manage their work in Zoho Desk. ### What you get * **One-click escalation from any request.** Click **Escalate ticket** in the request side panel, pick a Zoho Desk department and team, and a linked ticket is created with the Siit context pre-filled. * **Workflow-driven ticket creation.** Use **Create Zoho Desk ticket** as a workflow step, with approval gating where needed. * **Audit trail.** Every Zoho Desk action triggered from Siit is recorded on the request timeline. ### How it works 1. From the request side panel, click **Escalate ticket** and pick **Zoho Desk**. 2. Choose the department, team, channel, priority, and required fields. Fill in the subject and description. 3. Submit. Siit creates the Zoho Desk ticket, links it back to the Siit request, and posts the link on both sides. The same flow is available in workflows (as a **Create Zoho Desk ticket** action). ### What syncs from Zoho Desk * **Tickets created from Siit** — every escalated ticket is tracked with its Zoho Desk ticket number, department, and link. * **Links** — preserved between the Siit request and the Zoho Desk ticket, visible on both sides. > **Note** — bi-directional status sync is not currently available for Zoho Desk. Track resolution either through the Zoho Desk link on the request or by manually closing the Siit request when work is done. ### Custom field mapping > **Coming soon.** Custom field mapping for Zoho Desk is on our roadmap. For now, you can set the standard ticket fields when escalating. To track which fields are exposed, reach out via the in-app chat. ### Connect Zoho Desk * A Zoho Desk admin to authorize the connection. * Your Zoho data center region (zoho.com, zoho.eu, zoho.in, etc.) — Siit needs the right region during connect. 1. In Siit, go to **Settings → Integrations**, find **Zoho Desk** in the Ticketing section, and click **Connect**. 2. Pick your Zoho data center region. 3. Sign in to Zoho as an admin and approve the requested scopes. 4. Pick the department(s) and team(s) available for escalation. 5. Test by escalating a sample request from Siit to Zoho Desk. Need a more detailed walkthrough? Reach out to support via the in-app chat. ### Common workflows **Customer support escalation.** *Trigger: Service = "Customer escalation". Actions: Create Zoho Desk ticket in the support department → Set Siit priority to High → Notify requester.* **Specialist handoff.** *Trigger: Tag "advanced-support" added. Actions: Manager approval → Create Zoho Desk ticket → Notify requester.* ### Troubleshooting **"Authorization failed" on connect.** The admin signing in lacks Zoho Desk admin rights. Try with an admin who has full org access. **Wrong data center region.** Disconnect and reconnect with the correct region for your Zoho tenant. **Department or team missing.** The Siit Zoho Desk user lacks access to that department or team. Update access in Zoho Desk and re-sync. **"Ticket created" but no link in Siit.** The Zoho Desk ticket was created but the back-link save failed. Open the request timeline — the Zoho Desk ticket number is logged. Manually re-link if needed. # HRIS Connect Siit to your HRIS so your People data — employees, managers, departments, locations, employment types, start and end dates — flows automatically into every request, workflow, and report.
### Why connect your HRIS Your HRIS is the source of truth for who works at your company. Connecting it to Siit means: * **A directory that stays current.** New hires appear in Siit the day they're added in your HRIS. Leavers are flagged automatically. No more stale org charts or manual CSV imports. * **Richer context on every request.** Role, manager, department, location, legal entity, employment type, and start/end dates are attached to each requester — so routing, approvals, and SLAs can rely on them. * **Automated onboarding and offboarding.** Use **Start date** and **End date** triggers to launch full lifecycle workflows — create accounts, grant app access, ship equipment, and revoke everything at the right moment. * **Lifecycle-aware automations.** Probation reviews, work anniversaries, and birthdays can trigger touch points without anyone opening a ticket. * **Better reporting.** Slice metrics by department, office, legal entity, or employment type — because every request carries the HRIS attributes of its requester. ### What Siit syncs from your HRIS By default, Siit imports the fields you'll need most in requests, workflows, and reporting: * Identity: full name, work email, employee ID * Role: job title, level, department, cost center * Org structure: manager, team, location, legal entity * Employment: employment type (employee/contractor), status (active, pre‑hire, terminated) * Lifecycle dates: start date, end date, probation end, birthday You can extend the sync with custom fields from your HRIS, and decide which system wins for each field when multiple sources provide it (see Objects and Data model). > **Work email is the canonical identifier.** Siit matches people across your HRIS, IdP, and other tools using work email. Make sure it's populated and consistent before connecting. ### Supported HRIS Siit integrates natively with the most common HRIS platforms. Each one has its own setup guide: * [BambooHR](/integrations/hris/bamboohr) * [HiBob](/integrations/hris/hibob) * [Workday](/integrations/hris/workday) * [ADP](/integrations/hris/adp) * [Deel](/integrations/hris/deel) * [Rippling](/integrations/hris/rippling) * Personio * Gusto * Humaans * SAP SuccessFactors * Oracle HCM * Remote * Lucca * Payfit * Factorial * Sage HR * Namely * Paychex * Paylocity * UKG Pro * TriNet * Justworks * Kenjo * Charlie HR * Zoho People * AlexisHR Don't see yours? Reach out to your point of contact — we regularly add new HRIS connectors. ### How the sync works Once connected, Siit pulls People data from your HRIS on a regular schedule and keeps Siit in sync: * **Initial import** — all active employees are imported the first time you connect. * **Continuous sync** — Siit refreshes the directory automatically (typically every few hours, depending on the HRIS). * **Source of truth rules** — for each People field, pick which system wins if multiple are connected (e.g., HRIS for department, IdP for job title). Configure this in **Settings → People → Fields**. * **Lifecycle events** — start and end dates flow into Siit and can be used as workflow triggers, even before the employee has a user account anywhere else. ### HRIS + IdP: the best combination Many customers connect **both** an HRIS and an IdP (Okta, Entra ID, Google Workspace, JumpCloud). Here's how they complement each other: | | HRIS | IdP | | ---------------- | ----------------------------------------------- | ----------------------------------------- | | Source for | Employment data, org structure, lifecycle dates | Accounts, app access, authentication | | Triggers in Siit | Start / end dates, probation, anniversaries | User created, group membership changes | | Typical actions | Pre‑boarding sequences before accounts exist | Provisioning, SSO, group / app assignment | Connecting both lets you start a full **Day‑1 onboarding workflow** the moment a new hire is added to the HRIS — days before they ever log in — and cleanly offboard them when their end date arrives. ### Common use cases * **Day‑1 onboarding** — Trigger: Start date. Actions: create accounts in IdP, assign baseline apps, ship equipment, DM the hiring manager with a readiness checklist. * **Offboarding on end date** — Trigger: End date. Actions: revoke sessions, remove app access, open an equipment pickup request, notify the manager. * **Manager approvals** — Use the HRIS‑synced manager field to auto‑select the approver on any access or expense request. * **Audience targeting** — Publish services only to specific departments, locations, or legal entities straight from HRIS attributes. * **Probation reviews** — Trigger: Probation period. Action: send a review checklist to the manager. ### Getting started 1. Go to **Settings → Integrations** and pick your HRIS in the library. 2. Authorize the connection (each HRIS has its own flow — see the per‑platform guides). 3. Review the imported People and adjust field mapping in **Settings → People → Fields**. 4. Set the source of truth per field if you're also connected to an IdP. 5. Build your first lifecycle workflow in **Workflows → New → People trigger**. # BambooHR Connect BambooHR to Siit to sync your entire employee directory — active employees, pre‑hires, leavers, managers, departments, and locations — and power onboarding and offboarding workflows.
Bamboo's directory, lifecycle dates, and reporting structure drive Day-1 onboarding, offboarding, and access workflows, with custom fields mapped to your org structure. ### What you get * **Live People directory** — every BambooHR employee appears in Siit with their role, manager, department, location, employment type, and lifecycle dates. * **Lifecycle triggers** — Start date, End date, Probation period, Work anniversary, and Birthday all become workflow triggers in Siit. * **Manager resolution** — the BambooHR reporting structure is synced, so workflows can auto‑select the requester's manager for approvals. * **Custom fields** — extend the sync with the BambooHR fields specific to your organization (cost center, legal entity, job level, etc.). * **Pre‑hires and future start dates** — new hires appear in Siit before Day 1, so you can launch pre‑boarding workflows ahead of time. ### What syncs from BambooHR | Category | Fields | | --------------- | ---------------------------------------------------------------------------------------- | | Identity | First name, last name, work email, employee ID | | Role | Job title, department, division | | Org structure | Manager, office location, legal entity | | Employment | Employment status (active, inactive), employment type (full‑time, part‑time, contractor) | | Lifecycle dates | Hire date, termination date, date of birth | | Custom | Any custom field you select during mapping | Work email is used as the canonical identifier to match BambooHR employees with their accounts in your IdP and other connected tools. ### Before you connect * You'll need a BambooHR **admin account** or an API key from an admin‑level user. * Make sure work email is populated for every active employee in BambooHR. * Decide whether BambooHR or your IdP should be the source of truth for overlapping fields (job title, department). You can configure this after the connection in **Settings → People → Fields**. ### Connect BambooHR 1. In Siit, go to **Settings → Integrations**. 2. Find **BambooHR** in the HRIS section and click **Connect**. 3. Enter your BambooHR **subdomain** (the `yourcompany` part of `yourcompany.bamboohr.com`). 4. Generate a BambooHR API key: * In BambooHR, click your profile avatar (top right) → **API Keys**. * Click **Add New Key**, give it a name like "Siit integration", and copy the generated key. 5. Paste the API key into Siit and click **Authorize**. 6. Siit runs an initial import and shows you a preview of the people found. 7. Review the field mapping and click **Finish setup**. > **Tip** — API keys inherit the permissions of the BambooHR user who created them. Use an admin user so all employees and fields are available to Siit. ### After the connection * **Check your People list** — go to **People** in Siit and confirm the directory looks right. * **Set source of truth** — in **Settings → People → Fields**, pick BambooHR as the source for HR‑owned fields (department, manager, location, employment type, start/end dates). * **Map custom fields** — in **Settings → Integrations → BambooHR**, add any custom BambooHR field you want available in Siit. * **Build your first workflow** — try a Day‑1 onboarding workflow triggered on Start date. ### Sync frequency BambooHR data refreshes automatically every few hours. You can also trigger a manual sync from **Settings → Integrations → BambooHR → Sync now**. ### Common workflows **Day‑1 onboarding.** *Trigger: Start date. Actions: create accounts in IdP, assign baseline apps by department, ship equipment, DM the hiring manager.* **Offboarding on termination.** *Trigger: End date. Actions: revoke sessions, remove app access, create equipment pickup request, notify manager.* **Probation review.** *Trigger: Probation period. Actions: send review checklist to manager, open a request if no feedback after 3 days.* ### Troubleshooting **Some employees are missing from Siit.** Check their status in BambooHR — only active employees and future hires are synced by default. If you need inactive employees in Siit, adjust the import filter in **Settings → Integrations → BambooHR**. **Manager field is empty for some people.** In BambooHR, confirm that the employee has a reporting manager assigned in their Job Information tab. Siit reads from that field. **Custom field didn't appear.** Make sure the custom field is enabled for API access in BambooHR, then re‑run the mapping step in Siit. **"Invalid credentials" when connecting.** The API key has likely expired or been revoked. Generate a new one in BambooHR and update it in Siit. > # HiBob Connect HiBob to Siit to sync your employee directory and lifecycle events in real time — so onboarding, offboarding, and every request in Siit uses up‑to‑date HR data from Bob.
### What you get * **Live People directory** — Bob employees, departments, sites, and reporting lines appear in Siit automatically. * **Lifecycle triggers** — Start date, End date, Probation end, Work anniversary, and Birthday all flow into Siit as workflow triggers. * **Manager chain** — Bob's reporting structure powers auto‑selected approvals in Siit workflows. * **Custom fields** — import any custom Bob field into Siit (cost center, legal entity, work pattern, etc.). * **Pre‑hires** — future employees with a start date in Bob appear in Siit ahead of Day 1, so pre‑boarding workflows can run early. ### What syncs from HiBob | Category | Fields | | --------------- | --------------------------------------------------------------- | | Identity | Display name, first name, surname, work email, employee ID | | Role | Job title, department, team, job level | | Org structure | Manager, site (location), company / legal entity | | Employment | Employment type (employee, contractor), status (active, leaver) | | Lifecycle dates | Start date, termination date, date of birth | | Custom | Any custom Bob field you select during mapping | Work email is used as the canonical identifier across systems. ### Before you connect * You'll need **Bob admin permissions** to generate a service user and API token. * Make sure work email is filled in for every active employee in Bob. * Decide whether Bob or your IdP should be the source of truth for overlapping fields (title, department). You can configure this after connecting in **Settings → People → Fields**. ### Connect HiBob 1. In Bob, create a **service user** for Siit: * Go to **Settings → Integrations → Service Users**. * Click **New service user**, name it "Siit", and grant it read access to People, Employment, Work, and Lifecycle categories. * Copy the **Service user ID** and **token** shown. 2. In Siit, go to **Settings → Integrations**. 3. Find **HiBob** in the HRIS section and click **Connect**. 4. Paste the service user ID and token, then click **Authorize**. 5. Siit runs an initial import and shows a preview of imported people. 6. Review field mapping and click **Finish setup**. > **Tip** — Give the service user read‑only access to the People categories Siit needs. Avoid using a personal admin account; a dedicated service user survives employee changes. ### After the connection * **Check your People list** in Siit — the count should match your active + upcoming employees in Bob. * **Set source of truth** in **Settings → People → Fields**, picking HiBob for HR‑owned fields. * **Map custom fields** — in **Settings → Integrations → HiBob**, add any custom category or field you use in Bob. * **Build workflows** — start with a Day‑1 onboarding workflow using the Start date trigger. ### Sync frequency HiBob data refreshes automatically every few hours. Use **Settings → Integrations → HiBob → Sync now** to force an immediate refresh. ### Common workflows **Day‑1 onboarding.** *Trigger: Start date. Actions: create IdP account, assign app bundles by department, order equipment, DM the hiring manager.* **Offboarding on leave date.** *Trigger: End date. Actions: revoke sessions, remove app access, open an equipment return request, send handover reminder to manager.* **Welcome message by site.** *Trigger: Start date, Condition: site = Paris. Action: send the local welcome pack.* ### Troubleshooting **Missing employees.** Check that the service user has access to the employee's department. Bob permissions are category‑scoped, so missing access means missing data in Siit. **Manager field empty.** In Bob, confirm the employee has a manager set in the **Work** category. Siit reads from that field. **Custom field not imported.** Make sure the custom field is enabled in the API and within the service user's category permissions, then re‑run mapping in Siit. **"Unauthorized" on connect.** The service user token is invalid or the service user was deleted. Regenerate the token in Bob and paste it back into Siit. > # Rippling Connect Rippling to Siit to sync your workforce and lifecycle events. Rippling is often a single source of truth for HR, IT, and payroll.
Rippling's directory and lifecycle events drive Day-1 onboarding, offboarding, and access workflows, with Rippling-managed roles flowing into Siit's workflow conditions. ### What you get * **Live People directory** — Rippling employees and contractors appear in Siit with their full profile. * **Lifecycle triggers** — Start date, End date, Work anniversary, and Birthday flow into Siit as workflow triggers. * **Manager resolution** — Rippling's reporting structure drives auto‑selected approvers. * **Department, team, and location hierarchies** — preserved in Siit for routing, audiences, and reporting. * **Multi‑entity support** — for customers with multiple Rippling legal entities, each worker's entity is attached. ### What syncs from Rippling | Category | Fields | | --------------- | ------------------------------------------------------------------------------ | | Identity | Preferred name, legal name, work email, Rippling Employee ID | | Role | Job title, job level, department, team | | Org structure | Manager, work location, legal entity, cost center | | Employment | Employment type (Employee / Contractor), status (active, on leave, terminated) | | Lifecycle dates | Start date, termination date, date of birth | | Custom | Selected custom fields (Custom Field Groups you enable in Rippling) | Work email is the canonical identifier. ### Before you connect * You'll need **Rippling admin access** with permission to install third‑party apps. * Siit is installed via Rippling's app directory — your Rippling admin policy must allow this. * Decide which Rippling role / Custom Field Groups Siit should be able to read. ### Connect Rippling 1. In Siit, go to **Settings → Integrations**. 2. Find **Rippling** in the HRIS section and click **Connect**. You'll be redirected to Rippling. 3. Sign in to Rippling if prompted. 4. Review and approve the requested data scopes: * Read employees and contractors * Read departments, teams, work locations, legal entities * Read custom fields (if enabled) 5. Confirm the install. Rippling redirects you back to Siit. 6. Siit runs an initial import and shows a preview. 7. Review the field mapping and click **Finish setup**. > **Tip** — If you manage access strictly via Rippling Custom Roles, check with your Rippling admin that the admin performing the install has access to every employee you want synced. The scope is inherited at install time. ### After the connection * **Check your People list** in Siit — confirm the count matches Rippling's active employees + contractors. * **Set source of truth** — in **Settings → People → Fields**, pick Rippling for HR fields (department, manager, legal entity, employment type). * **Map custom fields** — in **Settings → Integrations → Rippling**, select which custom fields you want in Siit. * **Build workflows** — Rippling customers often want onboarding and offboarding workflows that pair HR data (Rippling) with provisioning steps (IdP, apps). ### Sync frequency Rippling data refreshes automatically every few hours. Force a manual sync from **Settings → Integrations → Rippling → Sync now**. ### Common workflows **Day‑1 onboarding.** *Trigger: Start date. Actions: create IdP account, assign department‑specific app bundle, ship equipment, notify manager.* **Offboarding on termination.** *Trigger: End date. Actions: revoke sessions, remove app access, create equipment pickup request, DM manager with handover reminder.* **Department‑aware routing.** *Condition: Requester's department = Engineering → Route to IT Ops; else → Route to general helpdesk.* **Contractor onboarding.** *Trigger: Start date, Condition: Employment Type = Contractor. Actions: create limited IdP account, assign contractor app bundle only.* ### Note on Rippling IT If you use **Rippling IT** for provisioning apps and devices in addition to HRIS, Siit currently consumes Rippling as an HR source of truth — provisioning actions triggered from Siit still flow through your IdP or the target apps directly. Reach out via in‑app chat if you'd like Rippling IT actions exposed natively in Siit workflows. ### Troubleshooting **Missing employees.** The installing admin's scope limits what Siit can see. Ask an admin with unrestricted scope to re‑authorize the connection from **Settings → Integrations → Rippling → Reauthorize**. **Custom field didn't appear.** Confirm the custom field is enabled at the API level in Rippling and included in the install scope, then re‑run mapping. **Manager is empty.** In Rippling, confirm a reporting manager is assigned on the employee's profile. **"App not authorized" on reconnect.** Rippling may have revoked the token after an admin change. Go through the install flow again. # Workday Connect Workday HCM to Siit to sync your workforce data — workers, managers, organizations, locations, positions, and lifecycle events — into every request, workflow, and report.
Worker hierarchies, supervisory orgs, cost centers, and legal entities drive multi-entity workflows, including pre-boarding flows that fire 30 days before Day 1. ### What you get * **Live People directory** — Workday workers (employees + contingent workers) appear in Siit with their full position data. * **Lifecycle triggers** — Hire date, Termination date, Probation end, Work anniversary, and Birthday flow into Siit as workflow triggers. * **Organization awareness** — Workday's supervisory, cost center, and location hierarchies are preserved so you can route, approve, and target by any org dimension. * **Manager resolution** — the Workday supervisory hierarchy powers auto‑selected approvers. * **Multi‑entity support** — legal entity, company, and region are synced and usable as conditions in workflows and audiences. ### What syncs from Workday | Category | Fields | | --------------- | ------------------------------------------------------------------------------- | | Identity | Preferred name, legal name, work email, Workday Worker ID, employee ID | | Role | Job title, job profile, job family, job level, position ID | | Org structure | Manager, supervisory organization, cost center, location, company, legal entity | | Employment | Worker type (Employee / Contingent Worker), employment status | | Lifecycle dates | Hire date, termination date, continuous service date, date of birth | | Custom | Selected custom worker fields | Work email is used as the canonical identifier. ### Before you connect Workday requires more preparation than most HRIS platforms. You'll need: * **Workday admin access** to configure an Integration System User (ISU) and a security group. * The **tenant URL** (e.g., `https://wd5-impl-services1.workday.com/ccx/service/yourtenant`). * Agreement with your Workday administrator on the scope of data exposed to Siit. ### Connect Workday Workday setup is a two‑part process: prepare credentials in Workday, then paste them into Siit. #### Part 1 — In Workday 1. **Create an Integration System User (ISU).** Create User → username `siit_isu`, set a strong password, and disable password expiration. 2. **Create a Security Group for the ISU.** Create a new **Integration System Security Group (Unconstrained)** named `Siit Integration`, and add the ISU as a member. 3. **Grant domain security policy permissions** (Get / Get All): * Worker Data: Public Worker Reports * Worker Data: All Positions * Worker Data: Workers * Manager: Worker Personal Data (for date of birth, if needed) * Organization Information (cost centers, supervisory orgs) * Any custom object/field you want exposed to Siit 4. Activate the pending security policy changes. 5. Locate and copy your **tenant URL** and **Workday REST API endpoint**. > **Tip** — If your Workday admin is cautious, start with read‑only access to Public Worker Reports and add domains incrementally as you identify fields you need in Siit. #### Part 2 — In Siit 1. Go to **Settings → Integrations**. 2. Find **Workday** in the HRIS section and click **Connect**. 3. Enter: * Tenant URL * ISU username and password 4. Click **Authorize**. Siit verifies the connection and runs an initial import. 5. Review the imported workers and field mapping, then click **Finish setup**. ### After the connection * **Verify counts** — compare the number of workers in Siit with an "All Active Workers" report in Workday. * **Set source of truth** — in **Settings → People → Fields**, make Workday the source for org‑structure fields (supervisory org, cost center, location, legal entity). * **Map custom fields** — if Siit is missing a field you expect, check the ISU's domain permissions and add the field in the Siit mapping screen. * **Build onboarding workflows** — Workday often becomes the trigger system for Day‑1 automation across IdP, apps, and equipment. ### Sync frequency Workday data refreshes every few hours by default. For very large tenants, the schedule is tuned based on worker count. Manual syncs are available from **Settings → Integrations → Workday → Sync now**. ### Common workflows **Pre‑boarding (30 days before start).** *Trigger: Start date − 30 days. Actions: send welcome email, notify manager to prepare a ready‑for‑Day‑1 checklist.* **Day‑1 onboarding.** *Trigger: Hire date. Actions: create IdP account, assign baseline app bundle by supervisory org, ship laptop.* **Offboarding on termination.** *Trigger: Termination date. Actions: revoke sessions, remove app access, equipment pickup request, notify manager.* **Legal entity‑aware approval.** *Condition: Requester's legal entity = "Siit France SAS" → Approval from French IT lead; else from global IT lead.* ### Troubleshooting **"401 Unauthorized" on connect.** The ISU password is wrong or the user has been locked. Reset the password in Workday and confirm the ISU isn't set to expire. **Workers missing.** The ISU security group likely lacks access to a supervisory organization or a worker type. Ask your Workday admin to extend the group's scope. **Custom field missing.** Make sure the custom field's domain is included in the ISU's security policy, then re‑map in Siit. **Sync is slow or incomplete.** Very large tenants can hit Workday API throttling. Contact Siit support — we can adjust the sync strategy (incremental, chunked) for your tenant. **Position vs. worker data.** Siit syncs worker‑level data by default. If you need position‑based attributes (e.g., position‑specific title), flag this during setup — we can enable position sync per tenant. > # ADP Connect ADP to Siit to sync your workforce data — workers, managers, departments, locations, job titles, and lifecycle events — so every request and workflow in Siit uses live HR data from ADP.
### What you get * **Live People directory** — ADP workers appear in Siit with their role, manager, department, and location. * **Lifecycle triggers** — Hire date, Rehire date, Termination date, Work anniversary, and Birthday flow into Siit as workflow triggers. * **Department and location hierarchies** — preserved for routing, audiences, and reporting. * **Manager resolution** — ADP reporting structure powers auto‑selected approvals. * **Multi‑company support** — for customers with multiple ADP companies, each one's workers are synced with their company / legal entity attached. ### What syncs from ADP | Category | Fields | | --------------- | --------------------------------------------------------------------------- | | Identity | Preferred name, legal name, work email, Associate ID (AOID), Worker ID | | Role | Job title, job code, job function, pay grade | | Org structure | Manager, department, location, company / legal entity, cost center | | Employment | Worker category (Employee / Contractor), status (active, leave, terminated) | | Lifecycle dates | Hire date, rehire date, termination date, date of birth | | Custom | Selected custom fields from ADP | Work email is the canonical identifier. Make sure it's populated in ADP before connecting. ### Before you connect * You'll need **ADP admin access** with authority to install marketplace apps. * Siit must be added to your ADP organization via the **ADP Marketplace**. Your ADP rep can help if the install is restricted. * Agree with your ADP admin on which worker categories and companies should be synced. ### Connect ADP #### Part 1 — In the ADP Marketplace 1. Sign in to the [**ADP Marketplace**](https://apps.adp.com/) as an admin. 2. Search for **Siit** and click **Buy Now** (it's free to install). 3. Review the data scopes requested and approve the subscription. 4. Once installed, the Siit app appears in **My Apps** with a Consent button. 5. Click **Grant Consent** — you'll be redirected to Siit to finalize the connection. #### Part 2 — In Siit 1. Siit automatically picks up the subscription created in ADP and opens the HRIS setup flow. 2. Review the imported workers (initial import can take a few minutes for large orgs). 3. Configure field mapping, including any custom fields you want to sync. 4. Click **Finish setup**. > **Tip** — If you don't see Siit in the ADP Marketplace, it may be restricted by your ADP organization's marketplace policy. Ask your ADP rep to enable marketplace self‑service. ### After the connection * **Verify counts** — compare Siit's People total with "Active Workers" in ADP Workforce Now. * **Set source of truth** — in **Settings → People → Fields**, pick ADP for payroll / employment fields (legal name, company, cost center). * **Custom fields** — if you use custom worker fields in ADP, add them in Siit's ADP settings after connection. * **Build workflows** — lifecycle workflows are usually the first thing customers build on top of an ADP sync. ### Sync frequency ADP data refreshes automatically every few hours. Trigger a manual sync from **Settings → Integrations → ADP → Sync now**. ### Common workflows **Day‑1 onboarding.** *Trigger: Hire date. Actions: create IdP account, assign apps by department, ship equipment, notify manager.* **Offboarding on termination.** *Trigger: Termination date. Actions: revoke sessions, remove app access, open equipment pickup request.* **Company‑aware approvals.** *Condition: Requester's company = "Siit US Inc." → Approver = US Finance lead.* **Rehire welcome‑back.** *Trigger: Rehire date. Actions: restore standard app bundle, DM manager with rehire checklist.* ### Troubleshooting **Consent screen doesn't redirect to Siit.** Close the popup and re‑open the Siit app in **ADP Marketplace → My Apps**. If consent was granted but Siit didn't pick it up, contact Siit support — we can trigger a manual sync. **Workers missing.** Check the subscription scope in ADP Marketplace — some installs default to a single company. Expand the scope to include all companies, then re‑sync. **Wrong manager or department.** These are pulled from ADP's current assignments. Confirm the worker's **Work Assignments** in ADP; Siit reflects what's active there. **"Consent expired" error.** ADP consents can be time‑limited for some tenants. Re‑grant consent from **ADP Marketplace → My Apps → Siit → Manage**. # Deel Connect Deel to Siit to sync your global workforce — employees, EOR workers, and contractors — and drive onboarding, offboarding, and request automation from Deel's lifecycle events.
### What you get * **Unified global directory** — Deel employees (EOR), direct employees, and contractors all appear in Siit, each with the right worker type. * **Lifecycle triggers** — Start date, End date, Probation end, and Birthday flow into Siit as workflow triggers. * **Contract and entity context** — country, legal entity, and contract type are synced so you can route and approve by location or contract. * **Manager resolution** — Deel's manager assignments power auto‑selected approvals. * **Contractor‑aware workflows** — differentiate between employees and contractors in every automation (e.g., skip laptop shipping for contractors). ### What syncs from Deel | Category | Fields | | --------------- | ------------------------------------------------------------------------------------------------- | | Identity | Full name, preferred name, work email, Deel Worker ID | | Role | Job title, seniority | | Org structure | Manager, team, country, legal entity / Deel entity | | Employment | Worker type (EOR Employee, Direct Employee, Contractor), contract status (active, pending, ended) | | Lifecycle dates | Start date, end date, probation end, date of birth | | Custom | Selected custom Deel fields | Work email is the canonical identifier. ### Before you connect * You'll need a **Deel admin** (Organization Admin or IT Admin) account. * Make sure work email is set on every worker record in Deel. For EOR employees, this is the corporate email you issue them — not their Deel login. * Decide whether Deel or your IdP is the source of truth for overlapping fields. ### Connect Deel 1. In Deel, generate an API token: * Go to **Organization Settings → Developer → API Keys**. * Click **Generate new token**, name it "Siit", and grant the scopes `people:read`, `contracts:read`, `organizations:read`. * Copy the token — it's shown only once. 2. In Siit, go to **Settings → Integrations**. 3. Find **Deel** in the HRIS section and click **Connect**. 4. Paste the Deel API token and click **Authorize**. 5. Siit runs an initial import and shows a preview. 6. Review field mapping (including the worker type mapping — confirm how you want EOR vs Direct Employee vs Contractor reflected in Siit's Employment Type field). 7. Click **Finish setup**. > **Tip** — If you only want employees (not contractors) synced into Siit, apply a filter on Worker Type in the mapping step. ### After the connection * **Check your People list** — confirm the counts by worker type match Deel's "People" view. * **Set source of truth** — in **Settings → People → Fields**, pick Deel for country, contract type, and legal entity. * **Map custom fields** — add any custom Deel fields you want in Siit. * **Build workflows** — Deel customers often start with offboarding automation driven by contract end date. ### Sync frequency Deel data refreshes every few hours. Force an immediate refresh from **Settings → Integrations → Deel → Sync now**. ### Common workflows **Global Day‑1 onboarding.** *Trigger: Start date. Actions: create IdP account, assign apps by team, ship equipment if Worker Type = Employee, send country‑specific welcome.* **Contractor offboarding.** *Trigger: End date, Condition: Worker Type = Contractor. Actions: revoke app access, notify manager, close Slack access.* **Entity‑specific approval.** *Condition: Requester's entity = "Siit SAS" → Approver = French HR lead.* **Pre‑boarding email 2 weeks before start.** *Trigger: Start date − 14 days. Action: email manager with a pre‑boarding checklist specific to the hire's country.* ### Troubleshooting **Workers missing.** Check the worker's contract status in Deel — only active and upcoming contracts are synced by default. Also confirm work email is set. **Contractor vs employee mis‑labeled.** Open **Settings → Integrations → Deel → Mapping** and confirm the Worker Type → Employment Type mapping. **Manager field empty.** In Deel, confirm the worker has a reporting manager under their profile. Siit reads from that field. **"Unauthorized" error.** The API token was revoked or is missing a scope. Generate a new one with the three scopes listed above and update Siit. > # Remote Connect Remote to Siit to sync your global workforce — full employees, EOR employees, and contractors — and drive onboarding, offboarding, and request automation from Remote's lifecycle events. ### What you get * **Unified global directory** — Remote employees, EOR workers, and contractors all appear in Siit with the right worker type. * **Lifecycle triggers** — Start date, End date, and Birthday flow into Siit as workflow triggers. * **Country and entity context** — country, legal entity, and contract type are synced so you can route and approve by location. * **Manager resolution** — Remote's manager assignments power auto‑selected approvers. * **Contractor‑aware workflows** — differentiate between employees and contractors in every automation. ### What syncs from Remote | Category | Fields | | --------------- | ------------------------------------------------------------------------ | | Identity | Full name, preferred name, work email, Remote worker ID | | Role | Job title, seniority | | Org structure | Manager, team, country, legal entity | | Employment | Worker type (EOR Employee, Direct Employee, Contractor), contract status | | Lifecycle dates | Start date, end date, date of birth | Work email is the canonical identifier. ### Before you connect * A Remote admin to generate an API token. * Work email populated on every worker record. For EOR employees, this is the corporate email you issue them — not their Remote login. ### Connect Remote 1. In Remote, generate an API token for Siit with read access to people, contracts, and organization data. 2. In Siit, go to **Settings → Integrations**, find **Remote** in the HRIS section, and click **Connect**. 3. Paste the API token, then click **Authorize**. 4. Review the imported people and field mapping (including Worker Type → Employment Type) and click **Finish setup**. Need a more detailed walkthrough? Reach out to support via the in‑app chat. ### After the connection * Confirm your **People list** matches Remote's active workforce. * In **Settings → People → Fields**, set Remote as the source of truth for country, contract type, and legal entity if you're also connected to an IdP. * Most Remote customers start with offboarding automation driven by contract end date. ### Sync frequency Remote data refreshes automatically every few hours. Trigger an immediate refresh from **Settings → Integrations → Remote → Sync now**. ### Common workflows **Global Day‑1 onboarding.** *Trigger: Start date. Actions: create IdP account, assign apps by team, ship equipment if Worker Type = Employee, send country‑specific welcome.* **Contractor offboarding.** *Trigger: End date, Condition: Worker Type = Contractor. Actions: revoke app access, notify manager, close Slack access.* **Entity‑specific approval.** *Condition: Requester's entity = "Acme SAS" → Approver = French HR lead.* ### Troubleshooting **Workers missing.** Only active and upcoming contracts sync by default. Confirm contract status and work email in Remote. **Contractor vs employee mis‑labeled.** Open **Settings → Integrations → Remote → Mapping** and check Worker Type → Employment Type. **Manager field empty.** In Remote, check the worker has a reporting manager set on their profile. **"Unauthorized" on connect.** The API token was revoked. Generate a new one and update Siit. # Personio Connect Personio to Siit to sync your employee directory and lifecycle events. Every request and workflow in Siit uses up‑to‑date HR data from Personio.
### What you get * **Live People directory** — Personio employees appear in Siit with role, manager, department, office, and lifecycle dates. * **Lifecycle triggers** — Hire date, Termination date, Probation end, Work anniversary, and Birthday flow into Siit as workflow triggers. * **Manager resolution** — Personio's reporting structure powers auto‑selected approvers in workflows. * **Pre‑hires** — future employees with a hire date in Personio appear in Siit ahead of Day 1. ### What syncs from Personio | Category | Fields | | --------------- | ---------------------------------------------------------- | | Identity | First name, last name, work email, employee ID | | Role | Position, department, sub‑company | | Org structure | Supervisor, office, legal entity | | Employment | Status, employment type | | Lifecycle dates | Hire date, contract end date, probation end, date of birth | Work email is the canonical identifier across systems. ### Before you connect * A Personio admin to create API credentials. * Work email populated for every active employee in Personio. ### Connect Personio 1. In Personio, go to **Settings → Integrations → API credentials** and generate a new credential pair for Siit. Grant read access to the attributes you want available in Siit (at minimum: name, email, position, department, office, supervisor, hire date, contract ends, status). 2. Copy the **Client ID** and **Client Secret** (the secret is shown only once). 3. In Siit, go to **Settings → Integrations**, find **Personio** in the HRIS section, and click **Connect**. 4. Paste the Client ID and Client Secret, then click **Authorize**. 5. Review the imported people and field mapping, then click **Finish setup**. Need a more detailed walkthrough? Reach out to support via the in‑app chat. > **Tip** — Personio API credentials are scoped at creation. Be intentional about which attributes you grant — adding new attributes later means creating a new credential pair. ### After the connection * Confirm your **People list** in Siit matches your active + upcoming Personio employees. * In **Settings → People → Fields**, set Personio as the source of truth for HR‑owned fields if you're also connected to an IdP. * Build a Day‑1 onboarding workflow using the Hire date trigger. ### Sync frequency Personio data refreshes automatically every few hours. Trigger an immediate refresh from **Settings → Integrations → Personio → Sync now**. ### Common workflows **Day‑1 onboarding.** *Trigger: Hire date. Actions: create IdP account, assign apps by department, ship equipment, DM supervisor.* **Offboarding on contract end.** *Trigger: Contract end date. Actions: revoke sessions, remove app access, equipment pickup, notify supervisor.* **Probation review.** *Trigger: Probation end. Action: send review checklist to supervisor.* ### Troubleshooting **Employees missing.** Confirm their status in Personio — by default only active and onboarding employees sync. Also confirm work email is populated. **Supervisor field empty.** In Personio, check the employee has a supervisor assigned. Siit reads from that field. **Custom attribute missing.** The API credential needs explicit access to each attribute. Generate a new credential pair with the broader scope. **"Invalid credentials" on connect.** The Client Secret was regenerated or revoked. Create a new credential in Personio and update Siit. # Gusto Connect Gusto to Siit to sync your US workforce — employees and contractors — and use Gusto's lifecycle events to drive onboarding and offboarding workflows. ### What you get * **Live People directory** — Gusto employees and contractors appear in Siit with role, department, manager, and worker type. * **Lifecycle triggers** — Start date, Termination date, and Birthday flow into Siit as workflow triggers. * **Manager resolution** — Gusto's reporting structure powers auto‑selected approvers. * **Employee + contractor coverage** — both worker types sync, with the type preserved as a Siit attribute. ### What syncs from Gusto | Category | Fields | | --------------- | -------------------------------------------------------------- | | Identity | First name, last name, preferred name, work email, employee ID | | Role | Job title, department | | Org structure | Manager, work location, company / legal entity | | Employment | Worker type (Employee / Contractor), status | | Lifecycle dates | Start date, termination date, date of birth | Work email is the canonical identifier. Compensation, payroll, tax, and benefits data are not synced into Siit. ### Before you connect * A Gusto admin account with permission to authorize third‑party apps. * Work email populated on every active worker. Gusto sometimes leaves this blank for contractors — fill it in first. ### Connect Gusto 1. In Siit, go to **Settings → Integrations**, find **Gusto** in the HRIS section, and click **Connect**. You'll be redirected to Gusto. 2. Sign in with your Gusto admin account. 3. Approve the requested read scopes (employees, contractors, departments, locations, jobs). 4. Gusto redirects you back to Siit, which runs an initial import. 5. Review field mapping (including Worker Type → Employment Type) and click **Finish setup**. Need a more detailed walkthrough? Reach out to support via the in‑app chat. > **Tip** — If your Gusto admin policy restricts third‑party app installs, ask your account owner to approve Siit before running the connection flow. ### After the connection * Confirm your **People list** matches Gusto's active workforce. * In **Settings → People → Fields**, set Gusto as the source of truth for HR‑owned fields if you're also connected to an IdP. * Most Gusto customers start with offboarding automation driven by termination date. ### Sync frequency Gusto data refreshes automatically every few hours. Trigger an immediate refresh from **Settings → Integrations → Gusto → Sync now**. ### Common workflows **Day‑1 onboarding.** *Trigger: Start date. Actions: create IdP account, assign apps by department, ship equipment if Worker Type = Employee, DM manager.* **Offboarding on termination.** *Trigger: Termination date. Actions: revoke sessions, remove app access, equipment pickup, notify manager.* **Contractor onboarding.** *Trigger: Start date, Condition: Worker Type = Contractor. Actions: create limited IdP account, contractor app bundle only.* ### Troubleshooting **Workers missing.** Only active workers and upcoming hires sync by default. Confirm status and work email in Gusto. **Contractor vs employee mis‑labeled.** Open **Settings → Integrations → Gusto → Mapping** and check Worker Type → Employment Type. **Manager field empty.** In Gusto, confirm the worker has a reporting manager set on their profile. **Connection shows "needs reauthorization".** OAuth tokens can be revoked or expire. Reconnect from **Settings → Integrations → Gusto**. **Multi‑company Gusto setups.** If you manage multiple companies in Gusto, reach out via in‑app chat — we'll confirm the right setup for your tenant. # Lucca Connect Lucca to Siit to sync your employee directory and lifecycle events. Lucca is widely used by French and European companies for HR, leave, and timesheet management.
### What you get * **Live People directory** — Lucca employees appear in Siit with role, manager, department, and lifecycle dates. * **Lifecycle triggers** — Hire date, End date, Work anniversary, and Birthday flow into Siit as workflow triggers. * **Manager resolution** — Lucca's reporting structure powers auto‑selected approvers in workflows. * **Pre‑hires** — future employees with a hire date in Lucca appear in Siit ahead of Day 1. ### What syncs from Lucca | Category | Fields | | --------------- | ----------------------------------------------- | | Identity | First name, last name, work email, employee ID | | Role | Job title, department | | Org structure | Manager, establishment / location, legal entity | | Employment | Contract type, status | | Lifecycle dates | Hire date, contract end date, date of birth | Work email is the canonical identifier across systems. ### Before you connect * A Lucca admin to generate an API key. * Work email populated for every active employee in Lucca. ### Connect Lucca 1. In Lucca, generate an API key with read access to the employee directory. 2. In Siit, go to **Settings → Integrations**, find **Lucca** in the HRIS section, and click **Connect**. 3. Enter your Lucca subdomain and the API key, then click **Authorize**. 4. Review the imported people and field mapping, then click **Finish setup**. For the detailed walkthrough, see our Help Center guide: [Lucca integration setup](https://help.siit.io/lucca-integration). ### After the connection * Confirm your **People list** matches your active + upcoming Lucca employees. * In **Settings → People → Fields**, set Lucca as the source of truth for HR‑owned fields if you're also connected to an IdP. * Build a Day‑1 onboarding workflow using the Hire date trigger. ### Sync frequency Lucca data refreshes automatically every few hours. Trigger an immediate refresh from **Settings → Integrations → Lucca → Sync now**. ### Common workflows **Day‑1 onboarding.** *Trigger: Hire date. Actions: create IdP account, assign apps by department, ship equipment, DM manager.* **Offboarding on contract end.** *Trigger: Contract end date. Actions: revoke sessions, remove app access, equipment pickup, notify manager.* ### Troubleshooting **Employees missing.** Only active employees and future hires sync by default. Confirm status and work email in Lucca. **Manager field empty.** In Lucca, check the employee has a manager assigned on their profile. **"Invalid credentials" on connect.** The API key was revoked. Generate a new one in Lucca and update Siit. # Factorial Connect Factorial to Siit to sync your employee directory and lifecycle events. Factorial is widely used by European SMBs for HR, time tracking, and payroll.
### What you get * **Live People directory** — Factorial employees appear in Siit with role, manager, department, and lifecycle dates. * **Lifecycle triggers** — Start date, End date, Work anniversary, and Birthday flow into Siit as workflow triggers. * **Manager resolution** — Factorial's reporting structure powers auto‑selected approvers in workflows. * **Pre‑hires** — future employees with a start date in Factorial appear in Siit ahead of Day 1. ### What syncs from Factorial | Category | Fields | | --------------- | ---------------------------------------------- | | Identity | First name, last name, work email, employee ID | | Role | Job title, department, team | | Org structure | Manager, work location, legal entity | | Employment | Contract type, status | | Lifecycle dates | Start date, end date, date of birth | Work email is the canonical identifier across systems. ### Before you connect * A Factorial admin to authorize the connection or generate API credentials. * Work email populated for every active employee in Factorial. ### Connect Factorial 1. In Siit, go to **Settings → Integrations**, find **Factorial** in the HRIS section, and click **Connect**. 2. Authorize the connection by signing in to Factorial as an admin. 3. Review the imported people and field mapping, then click **Finish setup**. Need a more detailed walkthrough? Reach out to support via the in‑app chat. ### After the connection * Confirm your **People list** matches Factorial's active workforce. * In **Settings → People → Fields**, set Factorial as the source of truth for HR‑owned fields if you're also connected to an IdP. * Build a Day‑1 onboarding workflow using the Start date trigger. ### Sync frequency Factorial data refreshes automatically every few hours. Trigger an immediate refresh from **Settings → Integrations → Factorial → Sync now**. ### Common workflows **Day‑1 onboarding.** *Trigger: Start date. Actions: create IdP account, assign apps by department, ship equipment, DM manager.* **Offboarding on end date.** *Trigger: End date. Actions: revoke sessions, remove app access, equipment pickup, notify manager.* ### Troubleshooting **Employees missing.** Only active employees and future hires sync by default. Confirm status and work email in Factorial. **Manager field empty.** In Factorial, check the employee has a manager assigned on their profile. **Connection shows "needs reauthorization".** Reconnect from **Settings → Integrations → Factorial**. # Payfit Connect Payfit to Siit to sync your employee directory and lifecycle events. Payfit is a popular payroll and HR platform for European SMBs.
### What you get * **Live People directory** — Payfit employees appear in Siit with role, manager, department, and lifecycle dates. * **Lifecycle triggers** — Hire date, End date, and Birthday flow into Siit as workflow triggers. * **Manager resolution** — Payfit's reporting structure powers auto‑selected approvers in workflows. * **Pre‑hires** — future employees with a hire date in Payfit appear in Siit ahead of Day 1. ### What syncs from Payfit | Category | Fields | | --------------- | ---------------------------------------------- | | Identity | First name, last name, work email, employee ID | | Role | Job title, department | | Org structure | Manager, work location, company / legal entity | | Employment | Contract type, status | | Lifecycle dates | Hire date, contract end date, date of birth | Work email is the canonical identifier. Compensation and payroll data are not synced into Siit. ### Before you connect * A Payfit admin to generate API credentials. * Work email populated for every active employee in Payfit. ### Connect Payfit 1. In Payfit, generate API credentials for Siit with read access to the employee directory. 2. In Siit, go to **Settings → Integrations**, find **Payfit** in the HRIS section, and click **Connect**. 3. Enter the credentials, then click **Authorize**. 4. Review the imported people and field mapping, then click **Finish setup**. Need a more detailed walkthrough? Reach out to support via the in‑app chat. ### After the connection * Confirm your **People list** matches Payfit's active workforce. * In **Settings → People → Fields**, set Payfit as the source of truth for HR‑owned fields if you're also connected to an IdP. * Build a Day‑1 onboarding workflow using the Hire date trigger. ### Sync frequency Payfit data refreshes automatically every few hours. Trigger an immediate refresh from **Settings → Integrations → Payfit → Sync now**. ### Common workflows **Day‑1 onboarding.** *Trigger: Hire date. Actions: create IdP account, assign apps by department, ship equipment, DM manager.* **Offboarding on contract end.** *Trigger: Contract end date. Actions: revoke sessions, remove app access, equipment pickup, notify manager.* ### Troubleshooting **Employees missing.** Only active employees and future hires sync by default. Confirm status and work email in Payfit. **Manager field empty.** In Payfit, check the employee has a manager assigned on their profile. **"Invalid credentials" on connect.** The credentials were revoked. Regenerate in Payfit and update Siit. # Humaans Connect Humaans to Siit to sync your employee directory and lifecycle events. Humaans is API‑first, so the integration is fast to set up and stays consistently in sync.
### What you get * **Live People directory** — Humaans employees appear in Siit with role, manager, department, location, and lifecycle dates. * **Lifecycle triggers** — Start date, End date, Probation end, Work anniversary, and Birthday flow into Siit as workflow triggers. * **Manager resolution** — Humaans' reporting structure powers auto‑selected approvers. * **Custom fields** — extend the sync with any custom Humaans field (cost center, contract type, etc.). * **Pre‑hires** — future employees with a start date in Humaans appear in Siit ahead of Day 1. ### What syncs from Humaans | Category | Fields | | --------------- | -------------------------------------------------------------- | | Identity | First name, last name, preferred name, work email, employee ID | | Role | Job title, department, team | | Org structure | Manager, location, legal entity | | Employment | Employment type, status | | Lifecycle dates | Start date, end date, probation end, date of birth | | Custom | Any custom field you select during mapping | Work email is the canonical identifier across systems. ### Before you connect * A Humaans admin to generate an API key. * Work email populated for every active employee in Humaans. ### Connect Humaans 1. In Humaans, go to **Settings → API access** and click **Create new key**. Name it "Siit integration", grant the required read access, and copy the key — it's shown only once. 2. In Siit, go to **Settings → Integrations**, find **Humaans** in the HRIS section, and click **Connect**. 3. Paste the API key and click **Authorize**. 4. Review the imported people and field mapping (including custom fields), then click **Finish setup**. Need a more detailed walkthrough? Reach out to support via the in‑app chat. > **Tip** — Humaans API keys inherit the permissions of the admin who created them. Use a dedicated service admin account so the integration survives admin turnover. ### After the connection * Confirm your **People list** matches your active + upcoming Humaans employees. * In **Settings → People → Fields**, set Humaans as the source of truth for HR‑owned fields if you're also connected to an IdP. * In **Settings → Integrations → Humaans**, add any custom Humaans field you want available in Siit. * Build a Day‑1 onboarding workflow using the Start date trigger. ### Sync frequency Humaans data refreshes automatically every few hours. Trigger an immediate refresh from **Settings → Integrations → Humaans → Sync now**. ### Common workflows **Day‑1 onboarding.** *Trigger: Start date. Actions: create IdP account, assign apps by department, ship equipment, DM manager.* **Offboarding on end date.** *Trigger: End date. Actions: revoke sessions, remove app access, equipment pickup, notify manager.* **Probation review.** *Trigger: Probation end. Action: send review checklist to manager.* ### Troubleshooting **Employees missing.** Only active employees and future hires sync by default. Confirm status and work email in Humaans. **Manager field empty.** In Humaans, check the employee has a manager assigned on their profile. **Custom field didn't appear.** Make sure the API key has access to the field, then re‑run mapping in Siit. **"Invalid credentials" on connect.** The API key was revoked or the admin who created it has been deactivated. Generate a new key in Humaans and update Siit. # Sage HR Connect Sage HR to Siit to sync your employee directory and lifecycle events. Sage HR is a common choice for SMBs across the UK, Ireland, and Europe.
### What you get * **Live People directory** — Sage HR employees appear in Siit with role, manager, department, and lifecycle dates. * **Lifecycle triggers** — Start date, End date, Work anniversary, and Birthday flow into Siit as workflow triggers. * **Manager resolution** — Sage HR's reporting structure powers auto‑selected approvers in workflows. * **Pre‑hires** — future employees with a start date in Sage HR appear in Siit ahead of Day 1. ### What syncs from Sage HR | Category | Fields | | --------------- | ---------------------------------------------- | | Identity | First name, last name, work email, employee ID | | Role | Job title, department | | Org structure | Manager, work location | | Employment | Status | | Lifecycle dates | Start date, end date, date of birth | Work email is the canonical identifier across systems. ### Before you connect * A Sage HR admin to generate an API key. * Work email populated for every active employee in Sage HR. ### Connect Sage HR 1. In Sage HR, generate an API key for Siit with read access to the employee directory. 2. In Siit, go to **Settings → Integrations**, find **Sage HR** in the HRIS section, and click **Connect**. 3. Paste the API key, then click **Authorize**. 4. Review the imported people and field mapping, then click **Finish setup**. Need a more detailed walkthrough? Reach out to support via the in‑app chat. ### After the connection * Confirm your **People list** matches Sage HR's active workforce. * In **Settings → People → Fields**, set Sage HR as the source of truth for HR‑owned fields if you're also connected to an IdP. * Build a Day‑1 onboarding workflow using the Start date trigger. ### Sync frequency Sage HR data refreshes automatically every few hours. Trigger an immediate refresh from **Settings → Integrations → Sage HR → Sync now**. ### Common workflows **Day‑1 onboarding.** *Trigger: Start date. Actions: create IdP account, assign apps by department, ship equipment, DM manager.* **Offboarding on end date.** *Trigger: End date. Actions: revoke sessions, remove app access, equipment pickup, notify manager.* ### Troubleshooting **Employees missing.** Only active employees and future hires sync by default. Confirm status and work email in Sage HR. **Manager field empty.** In Sage HR, check the employee has a manager assigned on their profile. **"Invalid credentials" on connect.** The API key was revoked. Generate a new one and update Siit. # SAP SuccessFactors Connect SAP SuccessFactors to Siit to sync your workforce data — workers, managers, departments, locations, and lifecycle events — into every request, workflow, and report.
### What you get * **Live People directory** — SuccessFactors workers appear in Siit with their full role and org context. * **Lifecycle triggers** — Hire date, Termination date, and Birthday flow into Siit as workflow triggers. * **Organization awareness** — department, cost center, location, and legal entity hierarchies are preserved for routing, approvals, and audiences. * **Manager resolution** — SuccessFactors' reporting structure powers auto‑selected approvers. * **Multi‑entity support** — legal entity, company, and region are synced and usable as workflow conditions. ### What syncs from SuccessFactors | Category | Fields | | --------------- | ---------------------------------------------------------- | | Identity | Preferred name, legal name, work email, person ID, user ID | | Role | Job title, job code, department, division | | Org structure | Manager, cost center, location, company, legal entity | | Employment | Worker type, employment status | | Lifecycle dates | Hire date, termination date, date of birth | Work email is the canonical identifier. ### Before you connect SuccessFactors requires more preparation than most HRIS platforms. Setup varies significantly by tenant configuration. You'll need: * A SuccessFactors admin to configure an OData API user and the relevant role-based permissions. * Your tenant URL and API endpoint. * Agreement with your SuccessFactors administrator on the scope of data exposed to Siit. For the recommended setup for your tenant, reach out to support via the in‑app chat — we'll work with you to scope and configure the connection correctly. ### Connect SAP SuccessFactors 1. Have your SuccessFactors admin create an OData API user with the required permissions to read worker data. 2. In Siit, go to **Settings → Integrations**, find **SAP SuccessFactors** in the HRIS section, and click **Connect**. 3. Enter your tenant URL, API user credentials, and any company-specific identifiers. 4. Review the imported workers and field mapping, then click **Finish setup**. ### After the connection * Compare Siit's worker count with your SuccessFactors active worker report. * In **Settings → People → Fields**, set SuccessFactors as the source of truth for org‑structure fields if you're also connected to an IdP. * Build a Day‑1 onboarding workflow using the Hire date trigger. ### Sync frequency SuccessFactors data refreshes every few hours by default. For very large tenants, the schedule is tuned based on worker count. Manual syncs are available from **Settings → Integrations → SAP SuccessFactors → Sync now**. ### Common workflows **Day‑1 onboarding.** *Trigger: Hire date. Actions: create IdP account, assign apps by department, ship equipment, DM manager.* **Offboarding on termination.** *Trigger: Termination date. Actions: revoke sessions, remove app access, equipment pickup, notify manager.* **Legal entity‑aware approval.** *Condition: Requester's legal entity → Route to the right regional approver.* ### Troubleshooting **"401 Unauthorized" on connect.** The API user password is wrong, expired, or the user has been locked. Reset and update Siit. **Workers missing.** The API user's role-based permissions likely lack access to a specific employee group or business unit. Ask your SuccessFactors admin to extend the permission scope. **Sync is slow on a large tenant.** Reach out via in‑app chat — we can adjust the sync strategy for your tenant. **Custom field missing.** Make sure the field is included in the API user's role permissions, then re-map in Siit. # TriNet Connect TriNet to Siit to sync your workforce and lifecycle events. TriNet is a US PEO and HR platform commonly used by SMBs and mid‑market companies.
### What you get * **Live People directory** — TriNet employees appear in Siit with role, department, manager, and lifecycle dates. * **Lifecycle triggers** — Hire date, Termination date, and Birthday flow into Siit as workflow triggers. * **Manager resolution** — TriNet's reporting structure powers auto‑selected approvers in workflows. ### What syncs from TriNet | Category | Fields | | --------------- | ---------------------------------------------- | | Identity | First name, last name, work email, employee ID | | Role | Job title, department | | Org structure | Manager, work location, company | | Employment | Worker type, status | | Lifecycle dates | Hire date, termination date, date of birth | Work email is the canonical identifier. Compensation, payroll, and benefits data are not synced into Siit. ### Before you connect * A TriNet admin with permission to authorize integrations. * Work email populated on every active worker in TriNet. ### Connect TriNet 1. In Siit, go to **Settings → Integrations**, find **TriNet** in the HRIS section, and click **Connect**. 2. Sign in with your TriNet admin account and approve the requested read scopes. 3. Review the imported people and field mapping, then click **Finish setup**. Need a more detailed walkthrough? Reach out to support via the in‑app chat. ### After the connection * Confirm your **People list** matches TriNet's active workforce. * In **Settings → People → Fields**, set TriNet as the source of truth for HR‑owned fields if you're also connected to an IdP. * Build a Day‑1 onboarding workflow using the Hire date trigger. ### Sync frequency TriNet data refreshes automatically every few hours. Trigger an immediate refresh from **Settings → Integrations → TriNet → Sync now**. ### Common workflows **Day‑1 onboarding.** *Trigger: Hire date. Actions: create IdP account, assign apps by department, ship equipment, DM manager.* **Offboarding on termination.** *Trigger: Termination date. Actions: revoke sessions, remove app access, equipment pickup, notify manager.* ### Troubleshooting **Employees missing.** Only active workers and upcoming hires sync by default. Confirm status and work email in TriNet. **Manager field empty.** In TriNet, check the employee has a manager set on their profile. **Connection shows "needs reauthorization".** Reconnect from **Settings → Integrations → TriNet**. # Namely Connect Namely to Siit to sync your employee directory and lifecycle events. Namely is a popular HRIS for US mid‑market companies.
### What you get * **Live People directory** — Namely employees appear in Siit with role, manager, department, and lifecycle dates. * **Lifecycle triggers** — Start date, Termination date, Work anniversary, and Birthday flow into Siit as workflow triggers. * **Manager resolution** — Namely's reporting structure powers auto‑selected approvers in workflows. * **Pre‑hires** — future employees with a start date in Namely appear in Siit ahead of Day 1. ### What syncs from Namely | Category | Fields | | --------------- | -------------------------------------------------------------- | | Identity | First name, last name, preferred name, work email, employee ID | | Role | Job title, department | | Org structure | Manager, office, legal entity | | Employment | Worker type, status | | Lifecycle dates | Start date, termination date, date of birth | Work email is the canonical identifier. Compensation and payroll data are not synced into Siit. ### Before you connect * A Namely admin to generate an API token. * Work email populated for every active employee in Namely. ### Connect Namely 1. In Namely, generate an API token for Siit with read access to the employee directory. 2. In Siit, go to **Settings → Integrations**, find **Namely** in the HRIS section, and click **Connect**. 3. Enter your Namely subdomain and the API token, then click **Authorize**. 4. Review the imported people and field mapping, then click **Finish setup**. Need a more detailed walkthrough? Reach out to support via the in‑app chat. ### After the connection * Confirm your **People list** matches Namely's active workforce. * In **Settings → People → Fields**, set Namely as the source of truth for HR‑owned fields if you're also connected to an IdP. * Build a Day‑1 onboarding workflow using the Start date trigger. ### Sync frequency Namely data refreshes automatically every few hours. Trigger an immediate refresh from **Settings → Integrations → Namely → Sync now**. ### Common workflows **Day‑1 onboarding.** *Trigger: Start date. Actions: create IdP account, assign apps by department, ship equipment, DM manager.* **Offboarding on termination.** *Trigger: Termination date. Actions: revoke sessions, remove app access, equipment pickup, notify manager.* ### Troubleshooting **Employees missing.** Only active employees and future hires sync by default. Confirm status and work email in Namely. **Manager field empty.** In Namely, check the employee has a manager assigned on their profile. **"Invalid credentials" on connect.** The API token was revoked. Generate a new one and update Siit. # Paychex Connect Paychex to Siit to sync your US workforce and lifecycle events. Paychex is a common payroll and HR platform for US small and mid‑market businesses.
### What you get * **Live People directory** — Paychex employees appear in Siit with role, department, manager, and lifecycle dates. * **Lifecycle triggers** — Hire date, Termination date, and Birthday flow into Siit as workflow triggers. * **Manager resolution** — Paychex's reporting structure powers auto‑selected approvers in workflows. ### What syncs from Paychex | Category | Fields | | --------------- | ---------------------------------------------- | | Identity | First name, last name, work email, employee ID | | Role | Job title, department | | Org structure | Manager, work location, company / legal entity | | Employment | Worker type, status | | Lifecycle dates | Hire date, termination date, date of birth | Work email is the canonical identifier. Compensation, payroll, and tax data are not synced into Siit. ### Before you connect * A Paychex admin with permission to authorize third‑party integrations. * Work email populated on every active worker in Paychex. ### Connect Paychex 1. In Siit, go to **Settings → Integrations**, find **Paychex** in the HRIS section, and click **Connect**. 2. Sign in with your Paychex admin account and approve the requested read scopes. 3. Review the imported people and field mapping, then click **Finish setup**. Need a more detailed walkthrough? Reach out to support via the in‑app chat. ### After the connection * Confirm your **People list** matches Paychex's active workforce. * In **Settings → People → Fields**, set Paychex as the source of truth for HR‑owned fields if you're also connected to an IdP. * Build a Day‑1 onboarding workflow using the Hire date trigger. ### Sync frequency Paychex data refreshes automatically every few hours. Trigger an immediate refresh from **Settings → Integrations → Paychex → Sync now**. ### Common workflows **Day‑1 onboarding.** *Trigger: Hire date. Actions: create IdP account, assign apps by department, ship equipment, DM manager.* **Offboarding on termination.** *Trigger: Termination date. Actions: revoke sessions, remove app access, equipment pickup, notify manager.* ### Troubleshooting **Employees missing.** Only active workers and upcoming hires sync by default. Confirm status and work email in Paychex. **Manager field empty.** In Paychex, check the employee has a manager set on their profile. **Connection shows "needs reauthorization".** Reconnect from **Settings → Integrations → Paychex**. # Paylocity Connect Paylocity to Siit to sync your US workforce and lifecycle events. Paylocity is a popular payroll and HR platform for US mid‑market companies.
### What you get * **Live People directory** — Paylocity employees appear in Siit with role, department, manager, and lifecycle dates. * **Lifecycle triggers** — Hire date, Rehire date, Termination date, and Birthday flow into Siit as workflow triggers. * **Manager resolution** — Paylocity's reporting structure powers auto‑selected approvers in workflows. ### What syncs from Paylocity | Category | Fields | | --------------- | -------------------------------------------------------------- | | Identity | First name, last name, preferred name, work email, employee ID | | Role | Job title, department, cost center | | Org structure | Manager, work location, company / legal entity | | Employment | Worker type, status | | Lifecycle dates | Hire date, rehire date, termination date, date of birth | Work email is the canonical identifier. Compensation and payroll data are not synced into Siit. ### Before you connect * A Paylocity admin with permission to authorize integrations. * Work email populated on every active worker in Paylocity. ### Connect Paylocity 1. In Paylocity, generate API credentials for Siit (Client ID + Secret) with read access to the employee directory. 2. In Siit, go to **Settings → Integrations**, find **Paylocity** in the HRIS section, and click **Connect**. 3. Enter the credentials, then click **Authorize**. 4. Review the imported people and field mapping, then click **Finish setup**. Need a more detailed walkthrough? Reach out to support via the in‑app chat. ### After the connection * Confirm your **People list** matches Paylocity's active workforce. * In **Settings → People → Fields**, set Paylocity as the source of truth for HR‑owned fields if you're also connected to an IdP. * Build a Day‑1 onboarding workflow using the Hire date trigger. ### Sync frequency Paylocity data refreshes automatically every few hours. Trigger an immediate refresh from **Settings → Integrations → Paylocity → Sync now**. ### Common workflows **Day‑1 onboarding.** *Trigger: Hire date. Actions: create IdP account, assign apps by department, ship equipment, DM manager.* **Offboarding on termination.** *Trigger: Termination date. Actions: revoke sessions, remove app access, equipment pickup, notify manager.* **Rehire welcome‑back.** *Trigger: Rehire date. Actions: restore standard app bundle, DM manager with rehire checklist.* ### Troubleshooting **Employees missing.** Only active workers and upcoming hires sync by default. Confirm status and work email in Paylocity. **Manager field empty.** In Paylocity, check the employee has a manager set on their profile. **"Invalid credentials" on connect.** The credentials were revoked. Regenerate them in Paylocity and update Siit. # UKG Pro Connect UKG Pro to Siit to sync your workforce and lifecycle events. UKG Pro is widely used by US mid‑market and enterprise companies for HR, payroll, and workforce management.
### What you get * **Live People directory** — UKG Pro employees appear in Siit with role, department, manager, and lifecycle dates. * **Lifecycle triggers** — Hire date, Termination date, and Birthday flow into Siit as workflow triggers. * **Manager resolution** — UKG Pro's reporting structure powers auto‑selected approvers in workflows. * **Multi‑entity support** — for multi‑company UKG tenants, each worker's company / legal entity is attached. ### What syncs from UKG Pro | Category | Fields | | --------------- | -------------------------------------------------------------- | | Identity | First name, last name, preferred name, work email, employee ID | | Role | Job title, department, cost center | | Org structure | Manager, work location, company / legal entity | | Employment | Worker type, status | | Lifecycle dates | Hire date, termination date, date of birth | Work email is the canonical identifier. Compensation and payroll data are not synced into Siit. ### Before you connect * A UKG Pro admin with API access enabled and permission to create service credentials. * Work email populated on every active worker in UKG Pro. ### Connect UKG Pro 1. In UKG Pro, generate API credentials (typically a service account with the relevant API role) with read access to employee data. 2. In Siit, go to **Settings → Integrations**, find **UKG Pro** in the HRIS section, and click **Connect**. 3. Enter the credentials and your UKG Pro tenant URL, then click **Authorize**. 4. Review the imported workers and field mapping, then click **Finish setup**. UKG Pro tenants vary in their API configuration. For the recommended setup for your tenant, reach out to support via the in‑app chat. ### After the connection * Confirm your **People list** matches UKG Pro's active workforce. * In **Settings → People → Fields**, set UKG Pro as the source of truth for HR‑owned fields if you're also connected to an IdP. * Build a Day‑1 onboarding workflow using the Hire date trigger. ### Sync frequency UKG Pro data refreshes automatically every few hours. Trigger an immediate refresh from **Settings → Integrations → UKG Pro → Sync now**. ### Common workflows **Day‑1 onboarding.** *Trigger: Hire date. Actions: create IdP account, assign apps by department, ship equipment, DM manager.* **Offboarding on termination.** *Trigger: Termination date. Actions: revoke sessions, remove app access, equipment pickup, notify manager.* ### Troubleshooting **Employees missing.** Only active workers and upcoming hires sync by default. Confirm status and work email in UKG Pro. Service account scope can also restrict what's visible — check with your UKG admin. **Manager field empty.** In UKG Pro, check the employee has a manager assigned in their job assignment. **"Invalid credentials" on connect.** The service account password expired or was rotated. Update Siit with new credentials. # Kenjo Connect Kenjo to Siit to sync your employee directory and lifecycle events. Kenjo is a popular HRIS for European SMBs and mid‑market companies.
### What you get * **Live People directory** — Kenjo employees appear in Siit with role, manager, department, and lifecycle dates. * **Lifecycle triggers** — Start date, End date, Work anniversary, and Birthday flow into Siit as workflow triggers. * **Manager resolution** — Kenjo's reporting structure powers auto‑selected approvers in workflows. * **Pre‑hires** — future employees with a start date in Kenjo appear in Siit ahead of Day 1. ### What syncs from Kenjo | Category | Fields | | --------------- | ---------------------------------------------- | | Identity | First name, last name, work email, employee ID | | Role | Job title, department, team | | Org structure | Manager, office, legal entity | | Employment | Contract type, status | | Lifecycle dates | Start date, end date, date of birth | Work email is the canonical identifier across systems. ### Before you connect * A Kenjo admin to generate an API key. * Work email populated for every active employee in Kenjo. ### Connect Kenjo 1. In Kenjo, generate an API key for Siit with read access to the employee directory. 2. In Siit, go to **Settings → Integrations**, find **Kenjo** in the HRIS section, and click **Connect**. 3. Paste the API key, then click **Authorize**. 4. Review the imported people and field mapping, then click **Finish setup**. Need a more detailed walkthrough? Reach out to support via the in‑app chat. ### After the connection * Confirm your **People list** matches Kenjo's active workforce. * In **Settings → People → Fields**, set Kenjo as the source of truth for HR‑owned fields if you're also connected to an IdP. * Build a Day‑1 onboarding workflow using the Start date trigger. ### Sync frequency Kenjo data refreshes automatically every few hours. Trigger an immediate refresh from **Settings → Integrations → Kenjo → Sync now**. ### Common workflows **Day‑1 onboarding.** *Trigger: Start date. Actions: create IdP account, assign apps by department, ship equipment, DM manager.* **Offboarding on end date.** *Trigger: End date. Actions: revoke sessions, remove app access, equipment pickup, notify manager.* ### Troubleshooting **Employees missing.** Only active employees and future hires sync by default. Confirm status and work email in Kenjo. **Manager field empty.** In Kenjo, check the employee has a manager assigned on their profile. **"Invalid credentials" on connect.** The API key was revoked. Generate a new one and update Siit. # Charlie HR Connect Charlie HR to Siit to sync your employee directory and lifecycle events. Charlie HR is a popular HRIS for UK and European small and mid‑market companies.
### What you get * **Live People directory** — Charlie HR employees appear in Siit with role, manager, department, and lifecycle dates. * **Lifecycle triggers** — Start date, End date, Work anniversary, and Birthday flow into Siit as workflow triggers. * **Manager resolution** — Charlie HR's reporting structure powers auto‑selected approvers in workflows. * **Pre‑hires** — future employees with a start date in Charlie HR appear in Siit ahead of Day 1. ### What syncs from Charlie HR | Category | Fields | | --------------- | ---------------------------------------------- | | Identity | First name, last name, work email, employee ID | | Role | Job title, team | | Org structure | Manager, office, legal entity | | Employment | Contract type, status | | Lifecycle dates | Start date, end date, date of birth | Work email is the canonical identifier across systems. ### Before you connect * A Charlie HR admin to generate an API key. * Work email populated for every active employee in Charlie HR. ### Connect Charlie HR 1. In Charlie HR, generate an API key for Siit with read access to the employee directory. 2. In Siit, go to **Settings → Integrations**, find **Charlie HR** in the HRIS section, and click **Connect**. 3. Paste the API key, then click **Authorize**. 4. Review the imported people and field mapping, then click **Finish setup**. Need a more detailed walkthrough? Reach out to support via the in‑app chat. ### After the connection * Confirm your **People list** matches Charlie HR's active workforce. * In **Settings → People → Fields**, set Charlie HR as the source of truth for HR‑owned fields if you're also connected to an IdP. * Build a Day‑1 onboarding workflow using the Start date trigger. ### Sync frequency Charlie HR data refreshes automatically every few hours. Trigger an immediate refresh from **Settings → Integrations → Charlie HR → Sync now**. ### Common workflows **Day‑1 onboarding.** *Trigger: Start date. Actions: create IdP account, assign apps by team, ship equipment, DM manager.* **Offboarding on end date.** *Trigger: End date. Actions: revoke sessions, remove app access, equipment pickup, notify manager.* ### Troubleshooting **Employees missing.** Only active employees and future hires sync by default. Confirm status and work email in Charlie HR. **Manager field empty.** In Charlie HR, check the employee has a manager assigned on their profile. **"Invalid credentials" on connect.** The API key was revoked. Generate a new one and update Siit. # Zoho People Connect Zoho People to Siit to sync your employee directory and lifecycle events. Zoho People is a flexible HRIS used globally, especially in mid‑market and growing companies.
### What you get * **Live People directory** — Zoho People employees appear in Siit with role, manager, department, and lifecycle dates. * **Lifecycle triggers** — Date of joining, Date of exit, Work anniversary, and Birthday flow into Siit as workflow triggers. * **Manager resolution** — Zoho People's reporting structure powers auto‑selected approvers in workflows. * **Pre‑hires** — future employees with a date of joining in Zoho People appear in Siit ahead of Day 1. ### What syncs from Zoho People | Category | Fields | | --------------- | ---------------------------------------------- | | Identity | First name, last name, work email, employee ID | | Role | Designation (job title), department | | Org structure | Reporting manager, location, legal entity | | Employment | Employment type, status | | Lifecycle dates | Date of joining, date of exit, date of birth | Work email is the canonical identifier across systems. ### Before you connect * A Zoho People admin with permission to authorize third‑party apps. * Work email populated for every active employee in Zoho People. * Note your Zoho data center region (zoho.com, zoho.eu, zoho.in, etc.) — Siit needs the right region during connect. ### Connect Zoho People 1. In Siit, go to **Settings → Integrations**, find **Zoho People** in the HRIS section, and click **Connect**. 2. Pick your Zoho data center region. 3. Sign in with your Zoho admin account and approve the requested read scopes. 4. Review the imported people and field mapping, then click **Finish setup**. Need a more detailed walkthrough? Reach out to support via the in‑app chat. ### After the connection * Confirm your **People list** matches Zoho People's active workforce. * In **Settings → People → Fields**, set Zoho People as the source of truth for HR‑owned fields if you're also connected to an IdP. * Build a Day‑1 onboarding workflow using the Date of joining trigger. ### Sync frequency Zoho People data refreshes automatically every few hours. Trigger an immediate refresh from **Settings → Integrations → Zoho People → Sync now**. ### Common workflows **Day‑1 onboarding.** *Trigger: Date of joining. Actions: create IdP account, assign apps by department, ship equipment, DM reporting manager.* **Offboarding on exit.** *Trigger: Date of exit. Actions: revoke sessions, remove app access, equipment pickup, notify reporting manager.* ### Troubleshooting **Employees missing.** Only active employees and future hires sync by default. Confirm status and work email in Zoho People. **Wrong data center region.** Disconnect and reconnect with the correct region for your Zoho tenant. **Manager field empty.** In Zoho People, check the employee has a reporting manager assigned. **Connection shows "needs reauthorization".** Reconnect from **Settings → Integrations → Zoho People**. # Justworks Connect Justworks to Siit to sync your US workforce and lifecycle events. Justworks is a popular PEO and HR platform for US small and mid‑market companies.
### What you get * **Live People directory** — Justworks employees and contractors appear in Siit with role, department, manager, and lifecycle dates. * **Lifecycle triggers** — Start date, Termination date, and Birthday flow into Siit as workflow triggers. * **Manager resolution** — Justworks' reporting structure powers auto‑selected approvers in workflows. * **Employee + contractor coverage** — both worker types sync, with the type preserved as a Siit attribute. ### What syncs from Justworks | Category | Fields | | --------------- | ---------------------------------------------- | | Identity | First name, last name, work email, employee ID | | Role | Job title, department | | Org structure | Manager, work location | | Employment | Worker type (Employee / Contractor), status | | Lifecycle dates | Start date, termination date, date of birth | Work email is the canonical identifier. Compensation, payroll, and benefits data are not synced into Siit. ### Before you connect * A Justworks admin with permission to authorize integrations. * Work email populated on every active worker in Justworks. ### Connect Justworks 1. In Siit, go to **Settings → Integrations**, find **Justworks** in the HRIS section, and click **Connect**. 2. Sign in with your Justworks admin account and approve the requested read scopes. 3. Review the imported people and field mapping (including Worker Type → Employment Type) and click **Finish setup**. Need a more detailed walkthrough? Reach out to support via the in‑app chat. ### After the connection * Confirm your **People list** matches Justworks' active workforce. * In **Settings → People → Fields**, set Justworks as the source of truth for HR‑owned fields if you're also connected to an IdP. * Build a Day‑1 onboarding workflow using the Start date trigger. ### Sync frequency Justworks data refreshes automatically every few hours. Trigger an immediate refresh from **Settings → Integrations → Justworks → Sync now**. ### Common workflows **Day‑1 onboarding.** *Trigger: Start date. Actions: create IdP account, assign apps by department, ship equipment if Worker Type = Employee, DM manager.* **Offboarding on termination.** *Trigger: Termination date. Actions: revoke sessions, remove app access, equipment pickup, notify manager.* **Contractor onboarding.** *Trigger: Start date, Condition: Worker Type = Contractor. Actions: create limited IdP account, contractor app bundle only.* ### Troubleshooting **Workers missing.** Only active workers and upcoming hires sync by default. Confirm status and work email in Justworks. **Contractor vs employee mis‑labeled.** Open **Settings → Integrations → Justworks → Mapping** and check Worker Type → Employment Type. **Manager field empty.** In Justworks, check the employee has a manager set on their profile. **Connection shows "needs reauthorization".** Reconnect from **Settings → Integrations → Justworks**. # AlexisHR Connect AlexisHR to Siit to sync your employee directory and lifecycle events. AlexisHR is a modern HRIS popular across the Nordics and Europe.
### What you get * **Live People directory** — AlexisHR employees appear in Siit with role, manager, department, and lifecycle dates. * **Lifecycle triggers** — Start date, End date, Work anniversary, and Birthday flow into Siit as workflow triggers. * **Manager resolution** — AlexisHR's reporting structure powers auto‑selected approvers in workflows. * **Pre‑hires** — future employees with a start date in AlexisHR appear in Siit ahead of Day 1. ### What syncs from AlexisHR | Category | Fields | | --------------- | ---------------------------------------------- | | Identity | First name, last name, work email, employee ID | | Role | Job title, department, team | | Org structure | Manager, office, legal entity | | Employment | Employment type, status | | Lifecycle dates | Start date, end date, date of birth | Work email is the canonical identifier across systems. ### Before you connect * An AlexisHR admin to generate an API key. * Work email populated for every active employee in AlexisHR. ### Connect AlexisHR 1. In AlexisHR, generate an API key for Siit with read access to the employee directory. 2. In Siit, go to **Settings → Integrations**, find **AlexisHR** in the HRIS section, and click **Connect**. 3. Paste the API key, then click **Authorize**. 4. Review the imported people and field mapping, then click **Finish setup**. Need a more detailed walkthrough? Reach out to support via the in‑app chat. ### After the connection * Confirm your **People list** matches AlexisHR's active workforce. * In **Settings → People → Fields**, set AlexisHR as the source of truth for HR‑owned fields if you're also connected to an IdP. * Build a Day‑1 onboarding workflow using the Start date trigger. ### Sync frequency AlexisHR data refreshes automatically every few hours. Trigger an immediate refresh from **Settings → Integrations → AlexisHR → Sync now**. ### Common workflows **Day‑1 onboarding.** *Trigger: Start date. Actions: create IdP account, assign apps by department, ship equipment, DM manager.* **Offboarding on end date.** *Trigger: End date. Actions: revoke sessions, remove app access, equipment pickup, notify manager.* ### Troubleshooting **Employees missing.** Only active employees and future hires sync by default. Confirm status and work email in AlexisHR. **Manager field empty.** In AlexisHR, check the employee has a manager assigned on their profile. **"Invalid credentials" on connect.** The API key was revoked. Generate a new one and update Siit. # Oracle HCM Connect Oracle HCM (Oracle Fusion Cloud HCM) to Siit to sync your workforce data — workers, managers, departments, locations, and lifecycle events — into every request, workflow, and report.
### What you get * **Live People directory** — Oracle HCM workers appear in Siit with their full role and org context. * **Lifecycle triggers** — Hire date, Termination date, and Birthday flow into Siit as workflow triggers. * **Organization awareness** — department, cost center, location, and legal entity hierarchies are preserved. * **Manager resolution** — Oracle's reporting structure powers auto‑selected approvers. * **Multi‑entity support** — legal entity, business unit, and region are synced and usable as workflow conditions. ### What syncs from Oracle HCM | Category | Fields | | --------------- | -------------------------------------------------------------- | | Identity | Preferred name, legal name, work email, person number, user ID | | Role | Job title, job code, department, division | | Org structure | Manager, cost center, location, business unit, legal entity | | Employment | Assignment type, employment status | | Lifecycle dates | Hire date, termination date, date of birth | Work email is the canonical identifier. ### Before you connect Oracle HCM setup varies significantly by tenant configuration. You'll need: * An Oracle HCM admin to create an integration user and grant the required REST API privileges. * Your Oracle HCM REST API endpoint URL. * Agreement with your Oracle administrator on the scope of data exposed to Siit. For the recommended setup for your tenant, reach out to support via the in‑app chat — we'll work with you to scope and configure the connection correctly. ### Connect Oracle HCM 1. Have your Oracle admin create an integration user with REST API privileges to read worker data. 2. In Siit, go to **Settings → Integrations**, find **Oracle HCM** in the HRIS section, and click **Connect**. 3. Enter your REST API endpoint, integration user credentials, and any tenant-specific identifiers. 4. Review the imported workers and field mapping, then click **Finish setup**. ### After the connection * Compare Siit's worker count with your Oracle HCM active worker report. * In **Settings → People → Fields**, set Oracle HCM as the source of truth for org‑structure fields if you're also connected to an IdP. * Build a Day‑1 onboarding workflow using the Hire date trigger. ### Sync frequency Oracle HCM data refreshes every few hours by default. For very large tenants, the schedule is tuned based on worker count. Manual syncs are available from **Settings → Integrations → Oracle HCM → Sync now**. ### Common workflows **Day‑1 onboarding.** *Trigger: Hire date. Actions: create IdP account, assign apps by department, ship equipment, DM manager.* **Offboarding on termination.** *Trigger: Termination date. Actions: revoke sessions, remove app access, equipment pickup, notify manager.* **Business unit‑aware approval.** *Condition: Requester's business unit → Route to the right regional approver.* ### Troubleshooting **"401 Unauthorized" on connect.** The integration user password is wrong or the account has been locked. Reset and update Siit. **Workers missing.** The integration user likely lacks REST privileges for a specific business unit or worker type. Ask your Oracle admin to extend the privilege scope. **Sync is slow on a large tenant.** Reach out via in‑app chat — we can adjust the sync strategy for your tenant. **Custom field missing.** Make sure the field is exposed via the relevant REST resource and the integration user has access, then re‑map in Siit. # MDM Connect Siit to your Mobile Device Management (MDM) platform so your device inventory, ownership, and remote actions flow directly into every request. Agents get full device context. ### Why connect your MDM Your MDM is the source of truth for every laptop, phone, and tablet in your fleet. Connecting it to Siit means: * **A live device inventory.** Laptops, phones, tablets, and peripherals from your MDM appear in Siit's Equipment inventory with model, OS, serial number, owner, and last check-in. * **Device context on every request.** When a request comes in, agents see the requester's assigned devices directly on the ticket — no copy-pasting serial numbers between tabs. * **One-click remote actions from any request.** Lock, wipe, and open in MDM from the request side panel. No more juggling three consoles to resolve a lost-laptop incident. * **Workflow-driven device lifecycle.** Use MDM actions in any workflow — automatic locks on reported theft, wipes on offboarding, reassignments during employee moves. * **Audit and traceability.** Every MDM action triggered from Siit is recorded on the request timeline, so you always know who did what and why. ### What Siit syncs from your MDM By default, Siit imports: * **Devices** — model, serial number, OS + version, asset tag, MDM device ID * **Ownership** — which user the device is assigned to * **Status** — enrolled, in service, reserved, lost, retired * **Last check-in** — when the device last reported to MDM * **Lifecycle events** — enrollment, un-enrollment, ownership change Devices are matched to people in Siit through the assigned user's email, so the full picture (requester → apps → devices) is available on every request. ### Supported MDM platforms Siit integrates natively with the four most common MDM platforms. Each one follows the same connection pattern — install, authorize, pick the scope — but the exact steps and capabilities vary by platform. * **Jamf** — for fleets standardized on Apple. Syncs devices and exposes Lock, Wipe, and Open in Jamf Pro actions. * **Iru (formerly Kandji)** — modern Apple MDM. Full device sync with Lock, Wipe, and Open in Iru actions. * **JumpCloud** — for teams using JumpCloud for device management in addition to (or instead of) identity. Syncs devices with Lock, Wipe, and Open in JumpCloud actions. * **Microsoft Intune** — for mixed Windows / macOS / mobile fleets managed through Microsoft Endpoint Manager. Syncs devices with Lock, Wipe, and Open in Intune actions. Using a different MDM (Mosyle, Hexnode, Workspace ONE, etc.)? Reach out via in-app chat — we're actively expanding MDM coverage and are collecting interest. ### What each integration covers | Capability | Jamf | Iru (Kandji) | JumpCloud | Intune | | ----------------------------------- | ---- | ------------ | --------- | ------ | | Device directory sync | ✓ | ✓ | ✓ | ✓ | | Ownership sync (user → device) | ✓ | ✓ | ✓ | ✓ | | Lock device | ✓ | ✓ | ✓ | ✓ | | Wipe device | ✓ | ✓ | ✓ | ✓ | | Open device in MDM console | ✓ | ✓ | ✓ | ✓ | | Available in the request side panel | ✓ | ✓ | ✓ | ✓ | | Available in workflows | Soon | Soon | Soon | Soon | | Available for IT Agent | Soon | Soon | Soon | Soon | ### How the sync works * **Initial import** — all enrolled devices and their assignments are imported the first time you connect. * **Continuous sync** — Siit refreshes device data automatically every few hours, so ownership and status stay current. * **Real-time actions** — Lock, Wipe, and other actions triggered from Siit execute immediately in the MDM. * **Matching** — devices are linked to people in Siit via the assigned user's email. Unassigned devices still appear in inventory but aren't attached to a requester. ### Using MDM actions in the side panel The fastest way to use an MDM integration is from the request side panel. On any request, the **Devices** section shows the requester's assigned devices. One click gives you: * **Assign** — assign or reassign a device to a user. * **Lock** — remotely lock the device (useful for lost or stolen devices). * **Wipe** — remotely wipe the device (for confirmed loss, theft, or offboarding). * **Open in MDM** — deep-link into the full device record in Jamf, Iru, JumpCloud, or Intune. Every action is logged on the request timeline, and sensitive actions can require an explicit confirmation step. ### Connecting an MDM Each MDM tool has its own connection flow, but the pattern is the same: 1. Go to **Settings → Integrations** and find your MDM in the library. 2. Authorize the connection — typically via an API key (Jamf, Iru, JumpCloud) or OAuth / app registration (Intune via Microsoft Graph). 3. Review the initial device import and scope (some customers want only corporate-owned devices, not BYOD). 4. Map device types to Siit's Equipment types (Computer, Smartphone, Tablet, Other) if not auto-detected. 5. Test by running a lock or open-in-MDM action from a sample request. ### Tips * **Use a dedicated service account** where possible (e.g., a "Siit Integration" API key in Jamf). The integration inherits that account's permissions, and a service account survives admin turnover. * **Gate Lock and Wipe behind approvals.** These actions are irreversible for the device owner. A quick manager approval in Slack adds five seconds and prevents a bad Monday. * **Pair MDM with HRIS for full lifecycle control.** Day-1 assignment and Day-N wipe become fully automated once both are connected. * **Keep Siit's Equipment records in sync as the source of truth for employees.** Siit is the friendly, employee-facing surface; the MDM is the technical execution layer. Both should tell the same story. --- [Next Page](/llms-full.txt/1)