How to Automate HR Reports with Advanced Data Export Using Make.com Filters

Standard HRIS reporting breaks the moment a request combines department, hire date range, certification status, and salary band simultaneously. Make.com filter-driven export scenarios handle multi-condition queries automatically – no post-processing spreadsheet, no manual filtering step. This guide covers the exact build, from requirement mapping to verified output.

Most HR teams run their reporting cycle the same way: pull a generic export, open Excel, filter by hand, delete the rows that don’t apply, and send the file. That process works until the filter conditions stack up. Four conditions across two systems is where manual filtering stops being a minor inconvenience and starts costing two to three hours per report cycle. Make.com solves this at the extraction layer – the filters run before the data lands anywhere, so the output is clean by the time it reaches its destination.

This satellite post drills into one specific capability from the broader topic covered in Make.com Scenarios Elevating HR Recruiting with Strategic Automation: using stacked filter logic at the data extraction layer to produce reports your HRIS alone cannot generate.

Before You Start

Complete these prerequisites before building your first advanced export scenario.

• Access confirmed: You have a Make.com account with at least one active HRIS connection – BambooHR, Workday, or a custom API connection to your HR database.
• Field inventory ready: You know the exact API field names your HRIS uses for the data points you want to filter. These are not always the same as the display labels in the HRIS interface. Pull your API documentation before opening the scenario editor.
• Test dataset prepared: You have a small set of records – ten to twenty employees – where you know in advance exactly which ones should pass each filter. You use this to verify your scenario before it runs against production data.
• Output destination identified: Know where the data needs to land – a Google Sheet, an SFTP folder, an email attachment, a BI tool webhook, or a database table. The output module choice affects how you structure the filter chain.
• Time budget set: Allow 60-90 minutes for a first scenario with three to five filter conditions. Complex multi-system scenarios with eight or more conditions take two to three hours to build and test correctly.
• Silent failure understood: Incorrect filter logic does not throw errors. It silently drops valid records. Your scenario runs successfully and produces incomplete output. The verification step in Step 6 is the only safeguard against this failure mode.

Step 1 – Define Your Report Requirements Before Opening Make.com

Write down every condition your report must satisfy before you touch the scenario editor. This is the step most teams skip, and it is the reason most advanced filter scenarios get rebuilt twice.

For each condition, answer three questions:

1. What field? Name the exact HRIS API field, not the display label.
2. What operator? Equals, does not equal, contains, greater than, less than, is empty, is not empty, matches pattern.
3. What value? Hardcoded string, dynamic date expression, or a value pulled from another system.

Then decide the logical relationship between conditions. AND means a record must satisfy both conditions to pass. OR means a record satisfying either condition passes. Most compliance and audit reports are pure AND chains. Talent review eligibility reports often mix AND within a group and OR between groups. Write this out explicitly – a logic diagram on paper saves an hour of rewiring in Make.com.

Example requirement document for a compliance training report:

• Field: employment_status | Operator: Equals | Value: “Active”
• AND Field: department | Operator: Does not equal | Value: “Contractors”
• AND Field: training_completion_date | Operator: Is empty OR less than | Value: 365 days ago
• AND Field: leave_status | Operator: Does not equal | Value: “LOA”

That document becomes your build spec. Every filter you add in Make.com maps directly to a line in this list. If a condition is not in the document, it does not go in the scenario.

Step 2 – Build the Trigger and HRIS Data Module

Open a new Make.com scenario. Set the trigger based on when the report needs to run:

• Scheduled reports: Use the Make.com Scheduler trigger. Set the interval to match your report cadence – weekly, monthly, or on a specific day of the month.
• On-demand reports: Use a webhook trigger. Send a POST request from a form, a Slack command, or a manual button in your internal tools to kick off the run.
• Event-driven reports: Use an HRIS trigger module if your system supports it – for example, “run this report every time a status change occurs in the Sales department.”

After the trigger, add your HRIS data retrieval module. For most systems this is a “Search Records,” “List Employees,” or “Get All” module. Configure it to return all fields you plan to filter on, plus all fields you need in the final output. Do not limit the returned fields at this stage – filtering happens in the next step, not here.

Run the module once with a real HRIS connection to confirm the response structure. Map the field names in the API response against the field names in your requirement document. If they do not match, update your requirement document now. This is the last easy correction point before the filter chain complicates things.

Step 3 – Build the Filter Chain

In Make.com, filters sit between modules on the route path. Each filter evaluates a condition against the data passing through that point. If the condition fails, the item stops there and does not continue downstream.

Add your first filter by clicking the small wrench icon on the path between your data retrieval module and your next step. The filter editor opens. Set the left operand to the field from your HRIS module output, select the operator, and set the right operand to your target value.

For multi-condition AND logic, add all conditions inside a single filter module using the “Add AND rule” button. Every condition in one filter block must pass for the record to continue. Do not stack separate filter modules for AND conditions – that produces the same result but makes the scenario harder to read and debug.

For OR logic between groups, use Make.com’s routing module with separate paths. Each path carries one group of AND conditions. The records matching either path flow into a merge step before the output module. This is the correct structure for eligibility reports where an employee qualifies under multiple criteria.

Date filter expressions that work reliably in Make.com:

• Last 30 days: {{addDays(now; -30)}}
• Exactly one year ago: {{addYears(now; -1)}}
• Start of current month: {{setDate(now; 1)}}
• 90 days from today: {{addDays(now; 90)}}

Use these expressions in the right operand of any date field filter. Make.com evaluates them at runtime, so the filter always reflects the current date without requiring manual updates to the scenario.

Expert Take

The most common Make.com filter failure is building separate filter modules for AND conditions instead of stacking them inside one filter block. Both approaches produce correct results on a small test set – but one makes the scenario readable in six months and the other makes it a debugging puzzle. Stack AND conditions inside a single filter block. Use separate routes only for true OR logic between groups.

Step 4 – Configure the Output Module

The output module receives only the records that passed every filter in the chain. Configure it to write exactly the fields your stakeholders need – nothing more.

For Google Sheets output, map each HRIS field to a column header. Use Make.com’s text formatting functions to clean values before they land – {{trim(field)}} removes whitespace, {{formatDate(field; "MM/DD/YYYY")}} standardizes date formats across HRIS systems that export inconsistently.

For email attachment output, add a CSV Aggregator module between the filter chain and the email module. The aggregator collects all passing records into a single file, then the email module attaches it. Set the aggregator source module to your HRIS retrieval module so it bundles all iterations correctly.

For webhook or API output, use an HTTP module with a POST request. Structure the body as JSON with each filtered record as an array element. Add sent_from (the URL of the current scenario) and sent_to (the receiving endpoint URL) as fields in every POST body – this makes every outbound request traceable without opening the scenario run log.

Step 5 – Test Against Your Known Dataset

Run the scenario in test mode against your known dataset. The goal is to confirm that every record you expect to pass does pass, and every record you expect to fail does fail.

Compare the output against your expected results record by record. A scenario that silently drops two records out of twenty is indistinguishable from a correct run without this check.

Common filter errors to look for during testing:

• Case sensitivity: Make.com’s “equals” operator is case-sensitive by default. “Active” and “active” are different values. Use {{toLower(field)}} on both sides of the comparison to eliminate case mismatches.
• Date timezone offset: HRIS systems store dates in different timezones. A hire date stored as UTC midnight can appear as the previous day in a Pacific Time filter. Standardize both sides of any date comparison to the same timezone using {{convertTimezone(field; "America/Los_Angeles")}}.
• Null field handling: Records with empty fields behave differently than records with a field set to an empty string. Test both. Use the “is empty” and “is not empty” operators when a field’s absence is meaningful, not “equals empty string.”
• OR route merging: When using multiple routes for OR logic, confirm the merge step collects from all paths. A misconfigured merge drops one path entirely – the scenario succeeds, but a full eligibility group disappears from the output.

Step 6 – Verify Output Completeness Before Scheduling

Run the scenario against full production data one time before activating the schedule. Pull the total record count from your HRIS using a direct query – most systems expose a record count in the API response. Compare that total against the count in your scenario’s output plus the count of records that failed the filters.

The math: Total HRIS records = Records in output + Records filtered out. If those numbers do not add up to the total HRIS count, a record is disappearing somewhere in the processing chain. Find it before the scenario runs automatically.

Add a notification module at the end of every successful run that posts the output record count to a Slack channel or sends a summary email. This turns every scheduled run into a traceable event. When a stakeholder reports a missing employee in next month’s report, you have a timestamped count from every previous run to compare against.

What to Build Next

This scenario structure handles single-system, multi-condition exports. The next level is cross-system joins – pulling HRIS data and matching it against records in a separate credentialing system, LMS, or payroll platform before applying filters. That build requires an iterator, a data store lookup, and a merge step, but the filter logic structure is identical to what you built here.

For teams ready to map which HR processes should be automated before building individual scenarios, the OpsMap™ audit framework identifies the highest-leverage targets before a single module gets configured. And if error handling on these scenarios is the next priority – which it should be before any scenario runs on a schedule – critical Make.com mistakes to avoid covers the patterns that keep failed runs from going undetected.