ReachCustom objects
Your organization, in its own words. A custom object is a record type you define yourself: you name it, choose its fields, and it works like the contacts and deals that ship with Reach. Grants, pledges, memberships, shifts, cases: model what you actually track, on the same machinery our own modules are built on.
Two ways to a type. Each with a page of its own.
- TemplatesNine record types ready to install (gifts, pledges, grants, memberships, shifts, cases and more), each arriving with its fields, stages and default view.
- AuthoringWhen the thing you track has no template: name it, give it fields from sixteen types, relate it to real people, and it exists, views, import and API included.
Install the shape of the work. Nine of them ship ready.
A template is a whole working type: the fields a grant application actually needs, the stages it actually moves through, the board it opens on. Install it, then bend it to your practice.
- Nine templates, named for the work they track
- Each arrives with fields, stages and a default view
- The nonprofit pack installs eight in one call
- Install it twice by accident and you still get one, not two
- Configure after: add fields, adjust stages and views
Or model your own. In an afternoon, not a quarter.
When the work has no template (equipment loans, bursaries, whatever your organization actually does), name it, give it fields, relate it to real people, and it exists with the same views and machinery as everything else.
- A name, a default view, and a link to the person or organization it’s about
- Fields from sixteen types, required where you say
- Validation you set: lengths, patterns, ranges
- Stage-sets where the work has a shape, none where it hasn’t
- Live the moment you save it: no developer, no ticket
Your new type, tracked like it was always here. Views, imports, API: nothing second-class about it.
Import and export, per type
Your grants spreadsheet becomes grant records through a mapped CSV wizard, and comes back out as a CSV just as cleanly.
Readable over the API
Every type and its records are readable over the REST API with scoped tokens. Your data model is not a black box.
First-class, not bolted on
Our own deals module is one of the nine templates. Your objects get the machinery we use ourselves, not a lesser copy.
Workflows can build them
A workflow can create a record of any type you’ve modelled: a gift record on every confirmed donation, without a hand on a keyboard.
Track what you actually track. The beta is open now.
Whatever you track in spreadsheets because your last CRM had no word for it: grants and their deadlines, pledges and their instalments, volunteer shifts, member renewals, casework. If it has fields and maybe stages, it can be a type.
No. Installing a template or authoring a type is done in the app: name, fields, relations, stages, views. The API is there for developers if you have them, not required because you don’t.
A tag says what something is called. A type says what it is: which fields it carries, what it relates to, what stages it moves through, and how it’s viewed. Tags collapse under real workloads; types are built for them.
Yes: add fields, adjust views and stages as the work teaches you. Modelling is a practice, not a one-time setup ceremony.
Not yet: the API today is read-only, by design, while the write path hardens. Records go in through the app or the CSV import; they come out through export and the API.