Modeling a Bill’s Journey through the U.S. House of Representatives

A bill's journey through the U.S. House of Representatives is modeled in Camunda Platform 8 and BPMN. Along the way, see how forms incorporate human tasks throughout the process and how DMN helps minimize errors.
  • Blog
  • >
  • Modeling a Bill’s Journey through the U.S. House of Representatives

30 Day Free Trial

Bring together legacy systems, RPA bots, microservices and more with Camunda

Sign Up for Camunda Content

Get the latest on Camunda features, events, top trends, and more.


I’ve been thinking about what it would look like to automate the process of passing laws in the U.S. government, so I decided to map out the whole process. Then it got complicated, so I decided to scale back and just start with how a law begins as a bill going through the House of Representatives.

It turns out that the process of moving a bill through the U.S. House of Representatives is pretty complicated and a great example for using Business Process Model and Notation (BPMN) to document, orchestrate, and automate a complex process.

Let me walk you through how I used Camunda Platform 8 to model this complicated process in BPMN and make it understandable. Along the way, you’ll learn how I added forms to include human interactions in the process and used a small Decision Model and Notation (DMN) decision table to minimize chances of error.

Follow along to do the same for the complicated processes you’re trying to tackle.

What we may already know

Now, if you grew up in the U.S. during a certain time this video from Schoolhouse Rock on how a bill becomes a law may be familiar to you.

Schoolhouse Rock- How a Bill Becomes a Law

There’s more to it, of course

Let’s start with the basics. The legislative branch of the U.S. government consists of the House of Representatives and the Senate. Together they make up the U.S. Congress and hold the sole authority to enact new or change existing laws.

Author’s Note: Buckle up, because I’m about to try to explain something here that, frankly, defies explanation. As I just said, the U.S. Congress is made up of the House of Representatives and the Senate. That’s the easy part. Each side of the U.S. Congress has two legislative sessions per year. This is called a Congressional Session. It is mandated in the Constitution that they each meet at least once every year, but they now do it twice. Here’s where things get weird. When a new House of Representatives is elected (which happens every two years), that starts what is called a Congress. So, to clarify, the U.S. Congress has two houses. Every two years starts a new Congress of those houses of Congress. Confused yet? I think that may have been the point, but I can’t prove it. It may be hard to keep this utterly clear distinction between the two uses of the word Congress separated as we go through this whole process. The best I can do is apologize.

The general idea this blog post follows is that a bill — a proposed law — is introduced in the House of Representatives and the members decide whether it will go to a committee or a subcommittee for discussion, debate, and what’s called markup. This is where the committee or subcommittee members make changes to the wording of the bill, etc.

Finally, the committee or subcommittee will vote on the bill. If it passes, it moves on to the next step. If the vote fails, the bill is dead and the whole process ends.

If the bill passes the subcommittee and the committee, it is then brought to the full House for debate. Once the full House has had a chance to read the bill and debate it, it is put to a vote by the full House.

If it passes the House, it is sent to the Senate where the whole process starts all over again.

Note: In reverse, if a bill is introduced in the Senate, and makes it all the way through there, the bill then goes to the House, where it is subjected to the entire process above.

That’s really the overly simplified version.

Mapping out the process

As with any process, it can be instructive to map the whole thing out so you can see all the various steps involved in completing it. That’s when I realized that things are actually a bit more complicated than they first appeared. There are all sorts of ways in which the process can end.

Here’s a simplified flowchart of the process:

courtesy of zen flowcharts

There are a lot of these flowcharts out there, but none of them are actually executable, so I decided to make that happen. Why would you want an executable flowchart? Great question! A flowchart is nothing more than a roadmap for how a process should go. Notice in the above chart we proceed from one activity to the next. But it’s nothing more than just a chart showing how things should go. There is no actual implementation to go along with it.

With BPMN, we can not only map out the process in a flowchart but also attach actions and results to each step in the process. BPMN is an executable language, so it not only shows the steps in a process, but it also defines the actions that each of those steps needs to take.

An executable flowchart

Using other flowcharts, information, and BPMN, I mapped out the entire process of a bill getting through the U.S. House of Representatives. Here it is:

The process

I’ve color-coded the process to make it easier to see what types of tasks I am using. In this particular process, I’m only using user tasks and business rule tasks. In fact, there are a lot of user tasks in there. A user task is a type of task where the workflow engine informs a user that there is a task that requires human intervention. It adds all of these tasks to Task List where users can go and see what pending work they might have to take care of. Typically, these user tasks require a user to fill out or respond to a presented form, which means I needed a lot of forms for users to fill out. Thankfully, there is an integrated form builder in Camunda 8, which I used to design the various forms.

I can now deploy this process, and then start an instance of it to see how it all works. This is actually an important point here. These are not just diagrams or flowcharts. Thanks to BPMN and the Camunda execution engine, they are also processes that can be directly executed.

When I deploy and start this process, I can go to Operate, which is the tool in the Camunda stack where you can see the actual execution state of your running process.

Starting the process

You can see the little green dot that indicates where in the process we are. The first thing we have to do is decide if this bill belongs in the House or the Senate. This is where the user task comes in. I designed a form for this user task asking one simple question: Is this bill an appropriations bill? Constitutionally, revenue-raising bills can only be introduced in the House. Traditionally, appropriations bills also start in the House.

Is this an appropriations bill?

If you look at the process above, you’ll figure out that if I were to say “no” here, the process would end because it only looks at how bills are introduced in the House. Technically this is incorrect, as any bill can be introduced in the House. I did this to show how the process could work.

Next, we will decide if the House will accept the bill. There are many reasons that the House may reject a bill; from it being poorly written, to there not being enough time to introduce it, etc. In our form, however, we just give it a straight thumbs-up or thumbs-down decision.

Is this bill accepted?

Notice that in Camunda Forms I can use emojis to make the form more fun. Congress could probably use more fun!

Once the bill is accepted, it is assigned to a committee for discussion, markup, and an initial vote.

Is this bill assigned to a committee?

There are a lot more committees in the House, but I decided to keep the list manageable for this example. Once the bill is sent to a committee, the committee decides whether or not to send the bill to a subcommittee for initial debate and markup.

Bill is in the subcommittee?

Once the bill is sent to a subcommittee, that subcommittee reads through the bill, makes any changes to it, and then takes a vote on whether or not to pass it along to the full committee.

Time to call the vote!

When the vote is called, all committee members have a chance to vote “aye” or “nay” as to whether the bill should pass through the subcommittee. A bill can sit in a committee (or subcommittee, or even the full House) indefinitely unless a vote is called. Typically, the committee chair or the House speaker would “call the vote” on a bill, but there is no requirement that a vote has to be held on any bill unless it is “called.”

And then a vote is held.

Subcommittee votes are tallied

Once the votes are collected, we use a DMN decision table to decide whether or not the bill has carried.

The decision table

The table takes the “ayes” and “nays” (yeses and noes) from the vote tally and decides whether or not the bill should be passed. In the event of a tie vote, the bill returns to the previous step for more debate and another vote. If it fails, the process ends there, but we are going to move it along.

By using a decision table, I can alleviate any accusations of vote-rigging shenanigans since no person has to make the decision, and the rules for the decision are clearly outlined in the table.

If we go back to Operate and look at the task and its progression, we can see that the bill passed through the subcommittee and now sits with the entire committee. We can also see all the history of the bill so far.

Bill is in committee

Again, by having the complete decision history and voting record, we can easily track how the bill has progressed along the way.

We are not going to go through every step in the process here, since the rest of the steps are basically repetitions or variations of steps we’ve already looked at.

Because each of the following steps is largely the same as the previous steps, I was able to reuse some of the forms and components I had already designed. I reused the “time for a vote” task, the “vote tally” task, and the vote-counting decision table. This ability to reuse previously designed elements is a huge benefit of using Camunda 8 to design and execute the process.

Finally, after the entire process is done (and the bill has passed the House) we can look back at the path that the bill followed.

Bill has passed the House

You can see that the path the bill followed is colored blue, so at any time we can go back, find the exact bill we are interested in, and see all of the history associated with it — including the path it took through the House.

Wait! There’s something else there

You’ve probably seen and been wondering about this little subprocess that’s been hanging around the whole time.

Constitutionally, a bill can only be considered in the Congress in which it was introduced (Please see the earlier note). If a bill has not either passed or been rejected by that particular Congress, it “expires” when new members are sworn in. That means it can no longer be considered or voted on. It would need to be introduced as a new bill and go through the entire process again.

To ensure that all the active bills are only considered during the current Congress, we have an expiration timer for all bills. This subprocess has a timer that expires on the date the new Congress is sworn in. If the timer goes off, any bill that has not passed is expired and can no longer be considered by the House.

The timer

As you can see, the timer will go off on January 1, 2023.  Once new members of Congress are elected this year (2022), they will join the upcoming Congress. When that new Congress is sworn in, all bills that have not been completed in the previous Congress will expire and be removed from consideration.


We have now mapped out the entire process for getting a bill through the U.S. House of Representatives. Although I started out this blog post showing you a couple of flowcharts for how the process works, those were just flowcharts. I couldn’t actually execute them as a process. By using Camunda Platform 8 to model the process in BPMN, I was able to transform it into an actual executable process. By adding forms with the integrated form builder, I was able to add human interactions to the process. In addition, using a small DMN decision table removed (hopefully) any chance of error in manually counting the votes to decide if the bill passed or failed.

So what’s missing? Well, this is just a small part of the overall process of turning a bill into law. The entire process is repeated over in the Senate (with a few differences). If the bill passed both houses, but one or the other made changes, the bill has to go to a conference committee where the changes are reconciled, so that the two versions match exactly. Once that’s done, the bill goes on to the president for their signature (or a veto).

If you’re interested in seeing the rest of the process developed, please reach out to me and let me know. Or feel free to check out the source code and make any additions or changes as a pull request.

Try All Features of Camunda

Related Content

An integral part of process orchestration is process automation—get those repeatable, well-understood tasks that don't require complex decision-making on autopilot!
Enhance your business's operational efficiency with business process management, and streamline your workflows to reduce cost and minimize risk.
Transition smoothly from design to implementation with an end-to-end business process. We'll show you how!