Leave management
Read and manage leave requests where your flow authorizes it, so coverage planning works from the real calendar.
The questions are ordinary: how many people are on each team, who is out next week, what does capacity look like for the quarter. The data lives in Rippling. The gatekeeping is right and proper, and it also means simple questions queue behind busy HR inboxes.
The Rippling connector answers the ordinary questions while keeping the gates. It links the AI you already use, like Claude, ChatGPT, or Copilot, to your Rippling instance through Mad Fish Elements, reading the workforce, organization, compensation, and time-and-attendance data your connection authorizes, and managing leave, groups, and custom objects where your flow calls for it. The sensitive system stays sensitive. The routine questions stop being tickets.
Connect your instance, and your AI reads what your Rippling authorization exposes, and only that: workers and their roles, the org structure they sit in, time and attendance, and the compensation data your scopes permit. The double gate is the design: Rippling's own API scopes decide what the connection can ever see, and Elements' per-person permissions decide who on your team can ask.
Within those gates, planning gets easy. "Headcount by department, and how it changed this year." "Who is on leave the first week of the campaign launch?" "What does the design team's capacity look like against the content calendar?" For marketing operations specifically, the people picture joins the work picture: the same Gateway reads Toggl and Workamajig, so staffing, hours, and project load can answer as one.
The write surface is deliberately administrative, not personal:
Read and manage leave requests where your flow authorizes it, so coverage planning works from the real calendar.
Maintain the group memberships that drive access and communication, shown and approved like everything else.
Read and manage the custom records your org models in Rippling, under the same gates.
The REST and Platform API surfaces are reachable through passthrough for what your scopes permit, so the odd authorized request stays supported.
What it deliberately is not: a way around HR. Compensation changes, employment actions, and anything personnel-sensitive stay in Rippling's own flows with the humans your policy names.
In practiceThe session marketing ops runs before every big push: the campaign launches the first week of November. You ask, "Who on the marketing and design teams is on approved leave that week?" Your AI returns the list: two designers out, one overlapping the heaviest build days. You ask, "What is the design team's tracked load looking like that week?" Toggl answers beside Rippling: the remaining designers are already near capacity. The launch plan shifts a deliverable earlier, this week, while shifting is cheap. The staffing surprise that usually arrives on launch morning arrived three weeks early, as a sentence.
Headcount, coverage, and capacity answered on demand, within your scopes.
Leave calendars and team load checked before dates get promised.
Managers see their slice; the gates hold for everyone else.
Rippling with Toggl and Workamajig, one conversation, when the question spans them.
"Headcount by department, with change since January."Rippling
The org picture as a visual report, within authorized scopes.
"Who is on approved leave during launch week?"Rippling
The coverage answer before the promise, not after.
"Add the three new hires to the marketing-tools access group."Rippling
Group membership maintained on approval, in the audit trail.
"Design team capacity next month against their tracked hours trend."Rippling · Toggl Track
People and workload in one answer.
"List open leave requests awaiting action."Rippling
The queue surfaced to the humans who decide.
Marketing ops and team leads get the planning answers their roles justify, without borrowing HR's afternoon. HR keeps the gates and loses the ticket noise.
For marketing teamsCapacity is the constraint behind every pitch promise. The staffing picture joins the hours and the project load on one Gateway, so "can we take this on" gets answered with the calendar, not optimism.
For agenciesAsk in chat and share the dashboard without building exports or taking screenshots.
Approved leave against key dates. Built for launch planning.
Teams, roles, and change over time. Built for the quarterly planning cycle.
People available against load trends. Built for the take-it-or-decline decision.
The charts stay sober here: bar for team comparison, calendar-style for coverage, line for headcount trend. And when leadership wants these anytime, the Data Visualization add-on turns your reports into always-current dashboards they open from a link. Ask in chat; share the dashboard.
Workforce planning runs on a modest set. Headcount by team, with change over time: the org's shape, moving. Coverage: who is out, when, against the dates that matter. Capacity outlook: people available against the load the work systems report. And open leave requests: the queue the humans decide. Deliberately absent from this list: anything personal. No individual performance metrics, no sensitive attributes, nothing your scopes exclude. The gates decide what exists here, and the planning figures above are what most teams gate in. Read coverage before every launch and headcount quarterly, and the ordinary questions stay answered without a single ticket. The extraordinary ones still go to HR, where they belong.
Day one: connect within the scopes HR approves; confirm what the connection can and cannot see. The gates are the feature; verify them first; day two: read the org. "Headcount by department." Day three: run the coverage check. "Approved leave over the next month against our launch dates." Day four: pair people with work. "Design team capacity against their tracked hours." Day five: schedule the planning brief. "Monthly, send the coverage calendar and headcount changes." By Friday, the routine planning questions answer themselves inside the gates, HR's inbox is quieter, and the next launch date got promised against a real calendar. Nothing sensitive moved; nothing sensitive will. The connector's first week is mostly proving that, and it should be.
Pair Rippling with Toggl Track for capacity against actual load, and with Workamajig for people beside projects. Keep access narrower than any other connector while doing it; the per-person permissions exist for exactly this pairing.
A closing note on posture; this connector succeeds by staying small. Narrow scopes; few users; planning questions only; if it ever feels like more than that, tighten it. The value is real: launches staffed on facts, coverage known in advance, headcount answered without a ticket. And the value survives any amount of caution. Set it up narrow; keep it narrow; let the answers earn their place.
It will not exceed your Rippling scopes; what the connection is not authorized to see does not exist to it. It will not handle employment actions, compensation changes, or anything personnel-sensitive; those stay in Rippling's own flows with your HR team. It will not become a surveillance layer; it answers planning questions from data your policy already shares. And access here should be, and can be, the narrowest of any connector: per-person permissions make that real.
Access is set per person, not per account, so Read seats see everything and change nothing while Write seats create and edit with your approval flow in front of every change. Delete access goes only to people you trust to clean up, and many teams start read-only, check answers against the platform, then widen access as the audit trail earns it.
You choose the level of human review and can change it at any time, while every action records what changed, when, and who approved it. Per-user access means Elements never stores your Rippling password, and your data is never harvested or resold.
Plans, account limits, and the multi-client Agency plan are on the pricing page .
Fewer people than any other connector; HR, ops leads, and managers with a planning need, mostly on Read. The per-person permission model exists for exactly this decision.
Only if your Rippling authorization includes it, and only for Elements users you permit. Most tenants scope compensation out of the connection entirely, which the double gate makes simple.
The administrative edges: leave workflows, group memberships, and custom objects your org models in Rippling. Everything shown first, approved by name, audited; personnel actions are not on this connector, by design.
No. Your AI acts only with the permissions you set, and changes follow the review level you choose. Read-only seats cannot change anything, because the approval flow is the product working as designed.
Your team can use Claude, ChatGPT, and Microsoft Copilot, while other AI tools can likely connect when they support MCP, the open standard for linking AI assistants to outside tools.
No. Your data stays yours, so nothing is harvested and nothing is resold.
The teams winning with AI are not handing their accounts to a black box; they keep the strategy and delegate the hands-on-keyboard work, while approvals and an audit trail make it safe to move fast. Connect the account you already have through the Gateway and ask the question you would normally build a report to answer.
Your first 14 days are free. Add your card to start, and cancel before the trial ends to pay nothing.