This pattern is less common than e.g. «Internal Order» yet it’s used quite often - probably once per each two BPMN classes.

Examples:

• Purchase by Tender
• Competitive Hiring

Simplified diagram depicts the essence of the pattern:

Full diagram:

Comments to the diagram:

1. The “Tender” process announces the tender, records the information in the tenders database for the future references by the bid process and falls asleep until the bid submission deadline. After that the tender record at the database is marked as closed.
2. Each sumbitted bid creates an instance of “Bid” process. Generally speaking we may run several tenders at once so the bid process starts by indentifying the specific tender the bid appllies to. It’s easy in the case of purchase by tender but when it comes to competitive hiring (where an income resume plays the role of the bid and the vacancy is tender’s equivalent) it’s a non-trivial task because people use to send resumes blindly not caring whether there is a suitable vacancy or not.
3. If the tender is successfully identified and the bid passes the qualification (in the case of hiring - the person passes interviews) then the bid is written into the database. The bid process then expects of one of two messages: either the bid is a winner or the tender has ended and the bid didn’t win.
4. The tender process sends the message to the winner after the best from the submitted bids has been choosen. There are two possible outcomes in the bid process: if everything goes smoothly we conclude an agreement with the winner. In this case a message is sent back to the tender process and the tender process informs other participants that their bids has not won. After that the tender process successfully ends.
5. If for whatever reason the agreement was not concluded then the tender process determines the next winner picking it from remaining bids. If there is no bids any more (or there were no bids from the beginning) then the tender process ends unsuccessfully.
6. It is assumed that the time interval between the bid submission and tender decision deadlines is sufficient to evaluate the request that may come “five minutes” before the submission deadline. If it happened that we evaluated all bids prior to the decision deadline then it’s possible to determine the winner earlier (not waiting for that date). In the case of hiring it makes sense while in the case of purchase probably not because in this scenario the end date is declared, well-known to participants and they usually submit the bids at the last moment. This logic can be modelled too but it would complicate the scheme considerably.

A couple of general notes:

• Repetitive actions are usually modeled in BPMN by a cycle (standard or multi-instance) or with the help of exclusive gateway. Here we model repetitive activities (processing bids) by a separate pool - each bid corresponds to an instance of the business process.
• The case for «Resource Planning» pattern is one performer / multiple orders. Here the situation is reversed: multiple potential performers for one task.