Skip to main content
Connect Rippling as your HRIS so Risotto can answer employee HR questions directly in Slack instead of routing them to your People team. Once connected, an employee can ask for their PTO balance, submit a time off request, check their job details, or look up the home address on file. In the dashboard, Rippling appears as a row under Settings > People > Connect with the description “Allows Risotto to manage HR operations like employee data and time off” and an Install button on the right.

​
Why connect Rippling

Deflect repetitive HR tickets

“How much PTO do I have left?” and “can I take next Friday off?” are among the most common requests People teams receive. Risotto answers them from live Rippling data.

Keep your roster current

Risotto syncs your employee roster from Rippling, so it knows who works there without you maintaining a separate user list.

Stop serving former employees

When someone is terminated in Rippling, Risotto stops acting on their requests.

No new surface for employees

Employees stay in Slack. They don’t need to remember where Rippling lives or how to navigate it.

​
Prerequisites

Have these in place before you start:
  • A Rippling admin account. Only Rippling admins can install App Shop apps.
  • A Risotto admin account. Installing, syncing, and disconnecting all require permission to manage the org.
  • Account provisioning configured for Risotto in Rippling. Rippling’s provisioning rules determine which employees are in scope for Risotto. These rules populate the PROVISIONING group that Risotto’s roster sync reads; without it, the sync has nothing to reconcile and reports a failure.
  • The Rippling company is not connected to another Risotto org. One Rippling company maps to exactly one Risotto org.

​
Install from the Rippling App Shop

Risotto connects to Rippling through the Rippling App Shop. The App Shop handles authentication and Risotto persists OAuth tokens automatically.
1

Start the install

Find the Risotto app in the Rippling App Shop and click Install, or start from the Risotto dashboard at Settings → People → Connect and click Install next to Rippling.
2

Approve the install in Rippling

Sign in to Rippling as an admin if prompted, then approve the requested permissions for the Risotto app. Rippling redirects you back to the Risotto dashboard once approval is complete.
3

Confirm the connection

Back in the Risotto dashboard, sign in if prompted and you’ll land on Settings → People → Connect, where the install finishes automatically. The Rippling row updates to show the integration is connected and begins its first employee sync.
4

Enable the actions you want

Installing the integration does not by itself let Risotto do anything. Go to Settings → People → Actions and enable each People Action you want available. To let the agent look up the employee record, turn on Agent access on the People tab of Support agent > Context. Every action is off until you turn it on.
Only Rippling admins can install App Shop apps. If the Install button redirects you to Rippling without an approval screen, ask an admin in your workspace to complete the install.
A Rippling company can only be connected to one Risotto org at a time. If the same Rippling company is already connected to another Risotto org, the install fails with “Please disconnect Rippling from your other Risotto org.” Disconnect from the other org first, then retry the install.

​
Requested Permissions

During install, Risotto requests access to the following Rippling data through the App Shop integration:
Rippling negotiates the exact permission scopes through the App Shop integration during approval. Risotto reads only the fields it needs to fulfill an active request.

​
Data Flows

The integration runs four distinct flows. Two keep your roster current in the background; two run only when an employee asks for something.

​
Employee roster sync

Risotto reads the PROVISIONING group from Rippling and reconciles its own roster against it. Employees in the group are added or updated; Rippling-sourced identities no longer in the group are marked inactive with an audit entry. This flow runs at three moments:
  • Once on install, so a new connection is populated immediately.
  • Once a day, in an overnight sweep (around 08:20 UTC).
  • On demand, when an admin clicks Sync now.
The sync is idempotent. Re-running it with no upstream change writes nothing. It’s also locked per org, so overlapping triggers collapse into the single run already in flight rather than stacking up.
The sync deliberately skips deactivating employees when the picture from Rippling looks incomplete such as an empty provisioning group, or a roster too large to read in one pass. A misconfigured group won’t silently deactivate your whole company.

​
Provisioning webhooks

Rippling notifies Risotto of employee lifecycle changes as they happen, so terminations don’t wait for the overnight sync: Webhooks are configured on the Risotto app itself, and your Rippling provisioning rules control which employees generate events.
Rippling delivers webhooks with a delay of roughly five minutes.

​
Employee data lookup

When an employee asks Risotto for their own HR data, Risotto calls Rippling live and reads only the fields that request needs. To find the employee, Risotto matches their email against Rippling’s work_email. The resolved Rippling worker ID is stored on the employee’s Risotto identity so later requests skip the lookup.

​
Time off request

The only flow that writes to Rippling. When an employee asks for time off, Risotto confirms the details with them first, then creates the request in Rippling with status pending, where it enters your normal approval flow. Risotto never approves anything.

​
Trigger a sync manually

To force an immediate roster sync without waiting for the overnight run, go to Settings → People → Connect, open the menu on the Rippling row, and click Sync now. The Rippling row reports the result inline:
The other three flows can’t be triggered by hand, and don’t need to be. Webhooks are sent by Rippling, and employee lookups and time off requests only ever run in response to an employee asking.

​
Data Fields That Sync

Risotto resolves the requesting employee’s Rippling worker record by matching their work email, then reads only the fields required to answer that request.

​
Employee profile (read)

Pulled from the Rippling workers endpoint:
Live lookups match on work_email only. personal_email is used as a fallback when the roster sync encounters a worker with no work email — so an employee whose Slack email matches neither field won’t resolve.

​
Home address (read only)

Read from the worker’s HOME-typed address record:

​
Time off (read and write)

Rippling stores leave amounts in minutes; Risotto surfaces them in hours.
Unlimited PTO policies don’t track a running balance, so Risotto surfaces those as unlimited rather than a literal number.

​
Supported Actions

Rippling supports the following People Actions:

Get Employee Info

Look up the requesting employee’s profile, title, department, work location, and start date. Turn it on in Support agent > Context.

Get Home Address

View the home address on file for the requesting employee.

Get PTO Balance

Retrieve balances for each policy type the employee is assigned to.

Request PTO

Submit a time off request for the requesting employee. Requests are created with status pending and follow your Rippling approval flow.
Update Home Address is not supported for Rippling. The Rippling API does not expose address writes, so employee addresses can only be edited in Rippling by the employee or an HR admin.

​
Terminated employees and rehires

When Rippling marks an employee as terminated or deleted, Risotto receives a webhook and immediately stops People Actions from running for that employee. Requests from former employees are escalated, even if their Slack account is still active. The daily roster sync catches anyone a missed webhook left behind. Rehires are handled automatically. Rippling issues a new worker ID when someone returns, so Risotto re-resolves them on their next request or on the next roster sync and reactivates their record.

​
Automation triggers

Rippling employee events can start a Risotto automation. In the trigger picker, open Rippling and choose Employee created, Employee hired, or Employee terminated. After you pick one, the header of the Trigger card shows Rippling’s own event name. The table uses those names. Rippling decides when it sends each event, not Risotto:
  • Use employee.created to start onboarding. It is the one event every new hire sends. Use employee.hired only for a step between offer acceptance and the start date.
  • employee.hired is not sent when you mark someone Hired, or on their start date. A hire you add on their start date goes straight to Active and gets only employee.created.
  • employee.created also comes for an existing employee when an access rule change gives them access to Risotto. A rule change that adds many employees at once starts a run for each one.
  • employee.terminated comes at the termination’s turn off app access time. With no time set, that is the day after the last day of work. Saving the last day does not send it, so the event can come days after HR enters the termination.
  • Rippling sends events only for employees with access to Risotto within Rippling. An employee your access rules leave out starts no run. employee.terminated is the exception: it still comes for an employee the termination itself removes from access.
The triggers need a working Rippling connection. If Rippling is not connected, or its connection needs to be reauthorized, the picker lists the events as unavailable with a link to Settings → People → Connect.

​
What the automation receives

All three triggers record the same fields about the person, which you can pin into instructions: When Rippling has no start or end date on file, the date Risotto received the event stands in for it.
Risotto skips an event for a worker with no valid work email, because it cannot resolve the event to a person. An automation runs once per employee and date for employee.hired and employee.terminated, and once per employee in 24 hours for employee.created, even if Rippling delivers an event more than once.

​
Disconnecting

Rippling stays installed on your org until an admin removes it in Rippling. To start, click Connected on the Rippling row, then click Disconnect…. In the Disconnect from Rippling? dialog, click Continue to Rippling to uninstall Risotto in the Rippling App Shop. Uninstalling in Rippling triggers a company.deleted webhook, and Risotto then deletes its stored access and refresh tokens and marks every Rippling-sourced employee record inactive.
Removing the app only in the Risotto dashboard is not enough. Until it’s uninstalled in Rippling, the connection remains live on Rippling’s side.

​
FAQs

No. Every People Action is scoped to the person making the request. An employee can retrieve their own PTO balance or home address, but cannot ask Risotto for a colleague’s. There is no manager or admin lookup path through this integration.
Not by itself, but an automation can do it. A Rippling event updates the roster and does not create a ticket. Create an automation on the Rippling employee.hired trigger and tell it to create the ticket. Rippling sends employee.hired when the hire accepts their offer or agreements, and only for employees in the Risotto app’s provisioning scope. A hire you add on their start date gets no employee.hired, so no run starts. For those hires, or to start from a step in your Rippling onboarding workflow, create an automation with a Webhook trigger and call its URL from that step.
No. The only write this integration performs is creating a time off request with status pending, which then follows your existing Rippling approval flow. Risotto cannot approve requests, edit profiles, change addresses, or modify payroll.
Yes. Submitting time off requires an explicit confirmation from the employee that is separate from their original message, so a casual mention of time off never creates a request on its own.
That’s a judgment call about PII. The action only ever returns the requesting employee’s own address, and it’s read-only. It does mean home addresses flow through your ticket source and any external ticket sync. If your policy restricts where address data may appear, leave it disabled. Every action is independently toggleable, so you can enable PTO features without it.
PTO balances, job details, and addresses are read live from Rippling at the moment of the request.
Rippling sends the termination webhook with a delay of roughly five minutes. For an immediate cutoff, click Sync now.
No. A Rippling company maps to exactly one Risotto org, so that webhooks route unambiguously. To move the connection, disconnect from the first org before installing in the second.
Scope is set by your Rippling provisioning rules, not by worker type. Anyone those rules place in the provisioning group is in scope; anyone they exclude is not. If contractors should be able to self-serve, confirm your Rippling provisioning rules include them.
Yes. Risotto sends the hours per day with the request when they differ from a standard eight-hour day, so part-day requests and part-time schedules are submitted correctly.
Yes. Risotto records org events for manual sync triggers, employee provisioning and deactivation, and the app uninstall.

​
Troubleshooting

This Rippling company is already connected to a different Risotto org. Disconnect it there first, then retry.
The install is time-limited, and a slow sign-in during the handoff can let it lapse. Retry the install from the Risotto app page in Rippling.
Rippling rejected the credential exchange. Retry the install. If it keeps failing, confirm you’re signed in as a Rippling admin and contact Risotto support.
Rippling has no provisioning group for Risotto to read, which almost always means account provisioning hasn’t been configured for the Risotto app yet. Set up provisioning rules in Rippling, then click Sync now.
Risotto’s stored credentials can no longer be refreshed and Rippling data is unavailable until an admin reconnects. Risotto notifies org admins when this happens. Reinstall from Settings → People → Connect; syncing is blocked until you do.
A transient Rippling API problem — a rate limit, a temporary outage, or a roster large enough to exceed the time limit. The next daily sync retries automatically; Sync now retries immediately.
Risotto couldn’t match them to a Rippling worker. Check, in order:
  1. Their Slack email matches their Rippling work_email.
  2. Rippling’s provisioning rules include them, so they’re in the group Risotto reads.
  3. They aren’t marked terminated in Rippling.
  4. A roster sync has run since they were added — click Sync now.
Confirm the actions are actually enabled. Installing the integration does not enable anything on its own — each action must be turned on under Settings → People → Actions.
Rippling validates requests against its own rules such as insufficient balance, blackout dates, policy restrictions, or overlapping requests. Risotto relays the reason Rippling gives. The employee can submit in Rippling directly if the rule needs an exception.
Check, in order:
  1. The employee has access to Risotto within Rippling.
  2. Rippling sent the event you expect. A same-day hire gets only employee.created, so use that trigger to catch every hire. employee.terminated waits for the access turn-off time.
  3. The employee has a valid work_email in Rippling.
  4. The Rippling connection does not need to be reauthorized.