CRUD is simply the Create, Read, Update, Delete that an application does.
To an extent, a bug tracker is a CRUD app too. Create bugs, Read (display) the bugs, Update the bugs, and maybe, delete them.
However, there is more to a bug tracker than just CRUD.
- A developer isn't allowed to mark the bug verified or closed - thats part of QA's job. And so some code is in there to make sure that someone who lacks the role of QA can't mark a bug as closed or verified.
- No one but a project manager can actually delete a bug.
- In order for a bug to be marked as "test me", there must be at least one commit of code against the bug.
- Only a bug that is in the 'closed' state may be moved to the 'reopen' state
- The developer assigned to the bug cannot move it from 'code review' to 'code review complete'
- QA and Developers can only see bugs on projects they are assigned to.
The code that implements the above is the business logic of the application.
The restriction of workflows, or who can do the various operations in CRUD. These are what separates one CRUD app from another. They are the parts where you need to get the business to actually say how the application works. How logical it is... well, thats best discussed over a beer out of the earshot of the project manager. But thats what business logic is.
Sure, its possible to write a 'pure' CRUD app where there are no roles, everything can be modified and viewed - but these are the exception rather than the rule.
The business logic is the logic that you are writing into your program to handle the business rules that you are given.
When you start getting into business rules, this tends to be be at a higher level than crud itself or business logic. This tends to be the things you get from a business analyst who is working with the business.
Consider in this example, a program that determines how to handle the return of an item at a returns desk in a store.
- If the receipt is equal to or more than 90 days old, only in store credit may be given
- If the receipt is less than 90 days old, credit the tender that the receipt was used to purchase with (credit goes back on the credit card, cash goes back to cash, in store credit goes to in store credit)... unless it was a check, in which case use cash.
Those are some business rules. They don't speak to the CRUD part of the application.
When working with business rules, you may often find these written in a rules engine (for example, Windows Workflow Foundation Rules Engine) instead of writing the raw code in your system.
Realize that the logic / rules distinction is one of terminology and can be argued all night long (best over a beer again). Though this isn't an uncommon distinction, though the two can blend into each other.