Good systems get out of your way.

At Flow State, we help mission-driven teams simplify the systems that support their work, so they can spend more time doing the work itself.With over a decade of Salesforce experience across nonprofits, education, and large-scale operations, we specialize in designing systems you'll need to use less. We focus on automating the routine, clarifying the messy, and giving people their time back. Our goal is to build systems that empower people to do the work only they can do and not get bogged down in tedious, frustrating workflows.Whether you're outgrowing your first CRM, buried under too many disconnected tools, or implementing Salesforce for the first time, we can help you untangle complexity, align systems with strategy, and bring the focus back to what matters: your mission.If that sounds like what you need, we'd love to hear from you.

• What We Do
• Who We Are
• Contact Us

• Back

• Back

^{What We Do}

Explore our offerings below.We work with Sales Cloud, Service Cloud, Field Service Lightning, and Nonprofit Success Pack, plus tools like Zapier, Typeform, FormAssembly, and OwnBackup.All packages are tailored to your needs and budget. Pricing available in USD or EUR.

• Org Audit
• Salesforce Implementation
• Flow State Support
• Case Studies

• Back

Contact Us

• LinkedIn
• Malt
• Salesforce

• Back

Org Audit

If your team is working around the system instead of with it, it might be time for a closer look.We’ll review how your org is structured; security, automation, layouts, and more; then flag the areas creating friction or slowing people down.You’ll get a clear, actionable roadmap to help clean things up and get Salesforce working the way it should.

• Back

Salesforce Implementation

Our Salesforce implementation service is an end-to-end setup tailored to your organization’s unique processes and workflows. Whether you're starting from scratch, migrating from another platform, or transitioning out of spreadsheets, we'll make sure you're set up for success, scale, and user adoption.

• Contact Us

• Back

Flow State Support

🔹Flow State Support: Basic

For teams that need small, tactical help without deep system changes.Clean dashboards. Better layouts. Useful reporting. Quick fixes that make life easier for end users.

What's Included:

Best for:
Teams with a working Salesforce org that just need a little day-to-day admin support

🔸Flow State Support: Advanced

When surface-level tweaks aren’t enough.
This tier is for untangling what’s gotten messy, whether it’s unclear permissions, outdated flows, or a setup that no longer fits how your team works.

What's Included:

Best for:
Orgs that have outgrown a one-size-fits-all setup and need help realigning Salesforce with how their team actually works, cleaning up automation, fixing permission issues, and untangling what’s no longer serving them.

💠Flow State Support: Embedded Solutions

What's Included:

Support that sees the full picture.
From daily fixes to long-term architecture, this is how you get high-level Salesforce leadership without hiring full-time.

Best for: Orgs with complex needs but no in-house architect, who want ongoing, high-context support to guide structure, untangle complexity, and align Salesforce with the company goals.

• Contact Us

• Back

Case Studies

Desk.com to Salesforce Service Cloud, With Ten Years of Case History Intact

A nonprofit's support desk had run on Desk.com for the better part of a decade when Salesforce set a hard shutdown date. We moved the whole operation onto Service Cloud in the weeks that were left, with nearly ten years of case history coming across intact and nothing archived. Four intake channels, a branded Experience Cloud Help Center backed by Salesforce Knowledge, Omni-Channel routing, and dashboards leadership could actually use. Customers didn't notice a thing, and agents found Service Cloud easier to work in than what it replaced.Read the full Desk.com to Service Cloud case study

Better Applicants and Real Reporting, Built on the Salesforce They Already Owned

A small nonprofit running job training and placement had its hiring stuck in email: resumes piling up in HR inboxes, no visibility for hiring managers, and nothing structured enough to report on, on top of applications that are sensitive enough to need locking down. They already owned Salesforce, so we built the applicant pipeline on it with Typeform on the front, no new licenses and no code. Every open role got a short hiring code published inside the job description, and that one field did two jobs: it routed each application to the right hiring manager through the sharing model, and it kept out anyone who hadn't read the posting. Candidate quality went up, leadership got its first real view of the hiring funnel, and HR ran the whole thing themselves for nearly a decade, with no developer and no help from us.Read the full nonprofit hiring pipeline case study

Admissions-First Salesforce for a Global Coding School

A global coding school was running admissions through a sales pipeline a previous consultancy had built for it. Opportunities stood in for applications, so the forecast was full of revenue that did not exist, and nothing in the model could represent a student who had been waitlisted. We rebuilt it around a real Application object, gated Opportunities behind acceptance, and turned programs and campuses into Products, so launching a new one meant adding a Product instead of reopening the data model. Thousands of records moved across in a single cutover alongside a Lightning rollout, and leadership got campus and program reporting it could finally trust.Read the full admissions data model case study

No Additional Cost Round-Robin Lead Assignment in Salesforce

Fair lead distribution without buying another tool. We built a round-robin entirely in Salesforce Flow, no code and no license, so leads got shared evenly and stopped sitting unworked. View the full Round Robin Case Study

Scaling a Multimillion-Dollar Tour Program in Salesforce, Without New Tools

Automated a multi-million-dollar international tour-operator program in Salesforce. Approved markets now create per-country Opportunities, pre-load products/quantities, generate contracts, and consume FormAssembly sales reports for live pacing, freeing the team to focus on partners and growth. View the full tour program case study

• Back

Desk.com to Salesforce Service Cloud, With Ten Years of Case History Intact

A nonprofit's multi-channel support desk, a vendor shutdown with a fixed date on it, and a few weeks to move a decade of customer history into Salesforce.

Salesforce had set 13 March 2020 as the date Desk.com would stop working, and that isn't the kind of deadline you can push a quarter. The client had run customer support on Desk for the better part of a decade, and the go/no-go on a successor didn't land until after the holidays, which left a few weeks to stand up Service Cloud, bring years of history across, and have customers notice nothing at all.What leadership wanted was clear and it didn't leave much room: functional parity with Desk, and all of the historical data inside Salesforce, no archiving. Support had been heavily tailored in Desk over the years, so a shallow lift and shift was never going to hold. Agents needed workflows they recognized on day one, managers needed to see load in real time, and everything else had to get as close to parity as the calendar allowed.

What we builtWe designed the Service Cloud backbone around how the team already worked rather than how Salesforce expects a support team to work. Desk inboxes became queues with assignment rules, and the common responses and multi-step actions agents had built up over the years became Quick Text and Macros. Omni-Channel went on for live routing and agent presence, paired with dashboards that showed leadership the KPIs they actually asked about.Cases arrived from four directions, and keeping all four was part of parity. Email into the support address, web forms embedded across other parts of the client's site, a web-to-case form on the Help Center itself, and live chat, which they used occasionally rather than as a front line. Salesforce's stock auto-response rules were too blunt to handle that spread, so we built the acknowledgement in Flow instead, which meant a form submission from one part of the site and an email into support could get different replies, and the conditions on the case could change them again.The Help Center we built on Experience Cloud, on the client's own domain, with Salesforce Knowledge behind it. Customers kept a familiar front door, and the ones who only needed an answer could find it without opening a case at all. This build is still powering their customer service to this day.
Then there was the history. Almost ten years of conversations and context lived in Desk, and the data migration had to land all of it in Salesforce and keep it readable, mapped so agents wouldn't lose the thread on a long-running relationship and leadership wouldn't lose its trendlines. We validated the whole build in a sandbox with support leadership and their power users, iterated on what came back, trained agents and managers, and went live in a single cutover.

How it landedFrom the outside it was uneventful, which is the entire goal in a migration like this. Acknowledgements went out, routing behaved, nobody sat through downtime. Inside, agents found Service Cloud easier to work in than Desk, and that's the part I'd point at first, because a migration can hit the date and still fail if people won't work in the thing you handed them. Managers had live visibility into workload for the first time. Leadership got standard dashboards instead of reports nobody could quite explain. And the full case history came across with the vendor's window still open.Without the move, the organization would have lost its external support platform outright. Instead they kept continuity, kept the institutional knowledge sitting in ten years of tickets, and came out of it with a Service Cloud implementation their own team could run day to day.

What We Delivered

If you're staring down a platform migration (especially one with a date on it), that's the kind of work we do, happy to talk through what that might look like for you.

• Let's Talk

• Back

Better Applicants and Real Reporting, Built on the Salesforce They Already Owned

A small nonprofit, a hiring process running on email, and a Salesforce org already paid for and busy tracking program outcomes.

The organization already had Salesforce. They just had it pointed at outcomes tracking and job placement metrics rather than at anything internal. Hiring ran on email, so resumes piled up in HR inboxes, hiring managers couldn't see where any candidate had got to, and a lot of what came in was from people who clearly hadn't read the posting. None of it was structured, so there was nothing to report on either.What they didn't have was budget or bandwidth for a rebuild. So rather than scope one, we proposed a pipeline that sat on top of the Salesforce instance they were already paying for. No new licenses, no custom development, and nothing that would need an admin's attention afterward.

How it worksTypeform on the front, Salesforce behind it. Job applications are sensitive, so the custom object they landed in was set to a private sharing model from the start. Which raises the obvious question of how an application then reaches the one manager who needs to read it, without somebody sitting there sharing records by hand all day.The hiring code answered that. Every open role got a short code, readable by a person, published inside the job description. Say the program team's role carried X32J4. Any application submitted with X32J4 was shared straight to that team's hiring manager, through criteria-based sharing rules and public groups. HR saw everything, each manager saw their own candidates, and nobody saw anything they had no business reading.The same field did a second job for free. An application with no code, or with a code that matched no open role, never made it into Salesforce at all. Typing it in meant somebody had read the posting to the end, and the ones who hadn't never reached anyone's queue.Manual sharing stayed available for the edge cases, because there are always edge cases. Rollout took a few weeks.

What it didHiring managers got the visibility and the controlled access the project was built for. What nobody had predicted was how much HR would come to value the other half of the hiring code. What reached them now came from people who had at least read the posting to the end, and the quality went up noticeably. HR could also start holding departments to their own review and interview timelines, because for the first time those dates sat somewhere everyone could see. Leadership got a view of the hiring funnel it had never had, and the reporting underneath it was consistent enough to act on.We built it in 2017 and it stayed in place for nearly a decade. In that time it took as many hiring codes as they cared to make, it came through every Salesforce release without a developer, and HR ran it themselves the whole way. That last part is the one I'd point at, because a system that needs me around to keep it working isn't finished.

What we delivered

If there's a process you'd like to migrate to a Salesforce org you're already paying for, that's exactly the kind of work we do. Happy to talk through what that could look like for you.

• Let's Talk

• Back

Admissions-First Salesforce for a Global Coding School

A coding school running admissions through a sales pipeline, thousands of applications a year, and a new campus or program landing about once a month.

The org had been built by another consultancy, and what they had built was a sales pipeline. Opportunities stood in for applications, and Leads and Contacts had been loaded with custom fields to approximate screening. That is a sensible shape for a company that sells things. It is the wrong shape for a school, and it is what you get when discovery runs against a template instead of against the business.Nearly every Opportunity in the system was really an application, so the pipeline showed revenue that did not exist and mostly never would. Reporting could not answer basic questions about how admissions ran across campuses, because the objects did not match the process. And an Opportunity has nowhere to put a student who has been waitlisted or deferred, because an Opportunity is a thing you are trying to close. Admissions had outcomes the data model could not hold.

What we builtAn Application object, as a child of Contact, carrying the stages admissions actually uses: Applied, Screened, then Accepted, Waitlisted, Rejected or Deferred. A Lead now converted into a Contact and conditionally an Application. An Opportunity was created only once a student had been accepted, so selling started when there was something to sell.Programs and campuses became Products with Price Books behind them, which is what made scholarships and discounts representable without anyone inventing a field for them. That is also the part that absorbed the growth. They were opening campuses and launching programs at close to one a month, and adding one now meant adding a Product and some light configuration rather than another change to the data model.On the inbound side, a marketing form had to arrive in Salesforce as two related records, a Contact and an Application, rather than as a single Lead with everything flattened into it. We ran HubSpot into Salesforce through Zapier to get that shape. It also meant the marketing team and the Salesforce team could each move without waiting on the other, which mattered at the rate new programs were appearing.

The migration, and the interfaceEvery existing record was migrated into the new structure, which is also what solved the in-flight problem. There was no window where a half-finished application sat in the old shape waiting for somebody to deal with it, because every one of them came across as a Contact with an Application attached, at whatever stage it had reached. Thousands of records, history preserved. We validated in a sandbox with leadership and senior reps, then went in a single cutover and trained the whole team.The old custom fields on Lead and Contact were deprecated rather than deleted. Pulled out of page layouts and out of reporting so nobody could keep working the old way by accident, with the data itself left where it was.This went out alongside Lightning Experience, in the summer of 2018. Stacking a full interface change on top of a data model replacement sounds like too much at once, and it was deliberate. Lightning was overdue anyway, and Salesforce had a reputation inside the building that was not a good one. A complete visual overhaul tells someone who does not care about data models the one thing they need to know, which is that this is not the same system they had learned to work around.

What changedNobody had to be talked into any of it. The design went to the engineering team first and then to admissions and sales, and there was not a single person in the building arguing to keep what they had, which tells you most of what you need to know about the old model. Buy-in was immediate and the whole thing came down to execution.After the cutover, Opportunities represented accepted students and real revenue work, so the pipeline number meant something for the first time. Time in the pipeline dropped by days to weeks depending on the program, helped by the reminders and nudges a standardized process could finally support. Campus and program reporting became straightforward, and leadership could trust the funnel numbers. Adding a program stayed a matter of adding a Product.What leadership said afterward was that Salesforce worked for them now, instead of the other way round.

What we delivered

If your Salesforce was built around a version of your business that has since moved on, that is exactly the kind of work we do. Happy to talk through what that could look like for you.

• Let's Talk

• Back

Round-Robin Lead Assignment in Salesforce, No Code and No License

The problemA coding-education provider needed a fair way to hand out sales leads, and they wanted it without buying another tool. At the time a manager assigned every lead by hand. It was a lot of work for the manager, and it left room for a few reps to hoard the good ones while other leads sat unworked. Their Sales and Business Development team was about ten reps, inside a Salesforce org of roughly 150 users. Managers needed to control the roster. Everyone else needed to trust it.

Why not just buy a toolBuying a routing tool was on the table, and we ruled it out on purpose. It came down to budget, simplicity, and bandwidth. Onboarding new software and managing another vendor is real work, and this problem did not need it. A round-robin is simple logic. It belonged in Salesforce, owned by the team, not behind another license.

What we builtWe built the whole round-robin in Salesforce Flow, with no code. Each eligible rep got two things added to their User record: a field that tracked their position in the rotation, and a flag for eligibility, for cases like being out of office or at capacity. As leads arrived, the Flow advanced the pointer to the next eligible rep and assigned the record.Managers could add or remove reps from the pool and flag people as eligible, and those changes took effect immediately, so leads never landed on someone who could not work them. No external license, no Apex, no mystery. Just visible logic the ops team could own.

The resultIt did exactly what the team needed. Leads were distributed evenly, hundreds of them over the life of the system, and they stopped piling up unworked in someone's name. The manager's time spent assigning leads by hand went to zero. The background noise of "who got what" quieted down.The process was fair by design, resilient when people were out, and easy to explain to a new hire. It cost nothing beyond internal admin time, fit cleanly into the org's existing Salesforce, and ran in production for years.

If we built it todayWe would keep the same principle, simple and auditable fairness. Today we would use custom metadata and records to capture weights, skills, and time-window rules, plus lightweight audit reporting. Flow can do more now than it could when we shipped this. The original still did the job: equal allocation, manager control, and a clear, no-cost path off manual assignment.

• Let's Talk

• Back

Scaling a Multimillion-Dollar Tour Program in Salesforce, Without New Tools

A two-person team was running a multimillion-dollar global program by hand. The organization, an international running-events group, partners with travel companies around the world to package race entries with travel. The revenue was serious. The tooling was not. The whole program ran inside a Salesforce org of about 200 users, on a workflow that had grown out of a generic internal process and never really fit.Too much was manual: reviewing applications, approving markets, creating contracts, setting up opportunities and line items, and chasing down periodic sales reports. It worked, but it was slow and brittle, and it ate most of the team's time.

The approachWe proposed a light re-architecture with targeted automation. Keep the stack they already had, and reshape Salesforce around how the program actually operates. No new tools.We kept FormAssembly for intake and made Salesforce the source of truth. On the Account, we added calculated rollups and formulas so the team could see year-over-year revenue and growth at a glance. We reshaped the custom Application object to capture exactly what they track in practice, not what a generic template assumed.

Automating opportunity and contract creation from a single approvalThe biggest lift was the sales and fulfillment side. A single approval often covers multiple countries and multiple races, and each country needs its own contract and revenue tracking. So we automated that turning point.When an application is approved for specific countries, Salesforce now creates one Opportunity per approved country and pre-loads the correct Products as line items, with the quantities allowed for that market. Commercial terms and contract records are generated with the right program details, country, and included races. What used to be a pile of clicks becomes a ready-to-work Opportunity that is already valued correctly.

Performance tracking that runs itselfWe also formalized ongoing performance. Operators submit periodic sales reports through FormAssembly, and those submissions now update the related records automatically, notify the team, and show whether an operator is pacing against their allocation. Reallocations and next-season approvals became evidence-based instead of email archaeology.

The resultBuild time was about three months, with continuous stakeholder feedback, UAT, and training. The day-to-day effect was immediate. The team cut manual handling of applications and deals by roughly half and put that time into outreach, partner management, and reporting. Leadership visibility improved.The program's revenue grew about 30% year over year after these changes. Growth has continued since, and plenty of factors contributed, but removing the bottlenecks and standardizing the process was a real part of it. And the model scales: adding a new country or race is a configuration, not a project.

Why it matteredA two-person team got out from under administrative busywork and could actually grow a global, high-value program. We standardized approvals, pricing, contracts, and performance tracking in Salesforce, without buying new tools or adding fragile complexity. Just the right automation in the right places.

• Let's Talk

• Back

The Team

• Back

Fenik Arroyo

Founder/Principal Consultant

You’ll notice this website says “we” a lot. For now, it’s the royal we, unless you count my dog, Ridley (her mouse and keyboard aren’t connected to anything, for your data’s protection).I’m a Salesforce Data Architect from New York City, recently relocated to the Netherlands to start Flow State Solutions. I focus on supporting mission-driven organizations because that’s how I’ve always lived my life. A mentor once introduced me to the Japanese concept of Ikigai, the intersection of four things:• Your passion (what you love + what you're good at)
• Your mission (what you love + what the world needs)
• Your calling (what the world needs + what you can be paid for)
• Your expertise (what you're good at + what you can be paid for)I got lucky and found myself right at the center of that intersection a decade ago. I love what I do, I’m good at it, and I get to support the work of people making a difference in the world, which makes what I do incredibly rewarding.Before going independent, I spent over a decade building and supporting systems at places like Flatiron School, WeWork, NYRR, and iMentor. I’ve worked across nonprofits, education, and fast-moving teams, so I’ve seen firsthand how good systems can empower great work. Yours should be next.

• Back

Any of my credentials can be verified using my full name 'Fenik Arroyo' and the trailhead verification tool found Here or clicking on any of the credentials above.

• Back

Ridley Arroyo

Chief Morale Officer

Ridley is not certified in Salesforce…yet. She does specialize in long naps by the desk, and enforcing a work/Ridley balance.

• Contact Us