Blocks are elements that can be added to forms and profiles, just like headers, fields, and instructions boxes.
Blocks typically display one or more fields in a logical group, and often provide code that performs actions in addition to displaying fields for simple data entry.
For example, the Address block displays several address fields, but also allows the zip code field to appear as the first field, then automatically fills in the city, state, and county fields by performing a lookup into the zip code table, and may do address validation and geocoding, display a Google Maps search link, etc.
Availability per Module
Blocks are generally designed to work for a specific module (Case/Matter, Timekeeping, Outreach, etc.). When editing forms and profiles, only the blocks available for that module should be listed. A limited number of blocks are available in multiple modules.
Use on the First Step of a Create Process
Many blocks need a record to exist to work, so they will not work on the first (or only) step of a create process (like a prescreen or intake). An example is the Family Information block. It must be on the second or later step of an intake.
Some blocks will display a friendly instruction element on the first step of a create process telling you it won't work. Some will make your process throw an error until you remove the block.
Behavior on Forms versus Profiles
Some blocks can be used on profile pages as well as forms. The Address and Applicant Phone #s blocks, for example, display editable fields on a form, but provide a nice 'summary' display of that information on a profile page.
Many blocks do not play nice on profile pages. The various Outcomes blocks, for example, do not; there is no Continue/Submit button to save any changes made. For these blocks, there is usually a corresponding list view that can be used to display the information on a profile page.
Most blocks provide configuration options that determine the fields that are displayed as well as the behavior of the elements displayed to users.