We are getting ready to launch a site for a client that makes heavy use of CiviCRM and CiviEvent.  During a pre-launch training on CiviCRM the client asked about best practices for using price sets. Each year the organization runs multiple events that have a variety of prices, but from year to year the prices change, and they wanted to know if they should change the prices in a price set or create a new price set. So here are some tips on using price sets in CiviCRM, this post does not explain the specific of configuring price sets, rather higher level ideas about planning how you are going to use them.

The benefits of using price sets is, in part, that if you use the same set of prices for multiple events you do not need to re-enter them each time, the same goes for using price sets on contribution pages.  It is important to note that when a site user makes a donation and contribution record is stored in the database. This records the amount of the contribution and the “source” or contribution page used to make the donation. If a user registers for an event online that requires payment, two records are created, one for the “contribution” or payment, and another for the “participant record”.

This second record, the participant record, stores (among other things) the “fee level” which is essentially the “label” of a particular price in the price set.  It also stores the amount that the user paid when they registered for the event.  If you subsequently change the amount associated with that “fee level” existing records are not updated.  The contribution record will also store the information about how much a user paid.

In our client’s scenario, the best practice is to disable a price set when the prices are no longer valid, and to create a new price set with the new values (each year).  You can only disable a price set if there are no active events or contribution forms using that price set. The reason for taking this approach is that historically you will have a better record of the fees associated with an event or contribution page, a record that would be lost if you were to change the fee amounts.

Another reason reason to use a new price set for your new fee structure is because there is no easy way (other than trying to deactive a price set) of finding out where the price set is used.  You might change a fee on a price set that is used in more than one place (contribution form or event registration form), even though you only wanted to change it for one form.

You can learn more about price sets on the CiviCRM documentation wiki.