This is a general database question, but I have a lookup table, StatusCodes, which has records such as accepted, canceled, pending, etc. The user wants access to this table to add additional codes for their own internal business purposes. I find my business layer making many references to the primary keys, such as :

If e.Status = 'A' then ...

...which is used to drive many of our business processes. I was wondering if this is a bad approach to handling things like this. Should I have another table that is used to drive things like this?

If I understand the question, basically you are using a type entity to classify an entity. So basically record A is a type of "widget", record B is a type of "foo".

If this is the case, it is quite common. When it comes to business rules, if you can find commonalities between "widget" types and "foo" types you can leverage the strategy pattern to invoke custom rules and processing instructions for "widgets" and "foos" using an abstract / reusable approach.

Yes it is common to do this. But stop using letters and start using integers. Primary keys shouldn't have any signficance or embedded attributes. What happens when you bust 26? Or change "Accepted" into "Final"? Or use a different language? So quit doing that.