# Create a functional area

Sets up a new group to organise the workforce into, with a target headcount and,
optionally, a set of conditions that keep its membership up to date on its own.
`code` has to be unique within the account and is stored in upper case whatever
case it is sent in. Switching `auto_update_mode` on makes `rules` mandatory - a
create that turns it on without well-formed conditions is rejected.
**The created group comes back with only the fields that were set on it**, not the
full record that reading it returns: anything left to its stored default is absent
rather than present and defaulted. Read the group back if you need its complete
state.

Endpoint: POST /api/v2/headcount/functionalarea
Version: 2.0.0
Security: default

## Header parameters:

  - `Rosterfy-Platform` (string)

## Request fields (application/json):

  - `name` (string, required)
    The name administrators see. Required.

  - `frontend_name` (string, required)
    The name volunteers see in the portal. Required, and shown in place of `name` to anyone without administrator access, so it is worth setting even when the two match.

  - `code` (string, required)
    A short reference for the group, unique within the account. Letters, numbers, dashes and underscores only - spaces and punctuation are rejected. Stored and returned in upper case whatever case it is sent in.

  - `headcount_functional_area_type_id` (integer)
    The ID of the group type to file this group under. Optional; omit or send null to leave the group untyped.

  - `target` (integer)
    How many people this group is aiming to have. `0` means no limit. Cannot be negative.

  - `auto_update_mode` (integer)
    Whether membership is maintained automatically from `rules`, and in which direction: `0` off, `1` add and remove, `2` add only, `3` remove only. When this is anything other than `0`, `rules` must be present and well formed or the request is rejected.

  - `rules` (array)
    The membership conditions used when `auto_update_mode` is on, as a list of condition objects built from the account's own user fields. Each condition names a field, a comparison and a value. Build these in the admin console and send back what it produces rather than composing them by hand - the set of addressable fields is specific to the account. **This field is cleared whenever it is omitted**, so resend it on every update to a group that has automatic updating switched on; omitting it there clears the conditions and the request is rejected.

  - `training_ids` (array)
    The IDs of the training modules assigned to anyone who joins this group. **Replaces the whole list** rather than adding to it, so send every module you want kept. Omitting the field leaves the stored list untouched.

## Response 201 fields (application/json):

  - `object` (object)

  - `object.rules` (array)

  - `object.auto_update_mode` (integer)

  - `object.name` (string)

  - `object.frontend_name` (string)

  - `object.code` (string)

  - `object.headcount_functional_area_type_id` (integer)

  - `object.target` (integer)

  - `object.training_ids` (array)

  - `object.account_id` (integer)

  - `object.updated_by` (integer)

  - `object.uuid` (string)

  - `object.updated_at` (string)

  - `object.created_at` (string)

  - `object.id` (integer)

  - `nice` (object)

  - `nice.rrn` (string)

  - `relations` (object)

  - `permissions` (object)

  - `permissions.read` (boolean)

  - `permissions.update` (boolean)

  - `permissions.delete` (boolean)