I think you should already be able to do the former, for most fields. Here's a screenshot from my local install -- note custom fields like "Autobiography" and "Nut Allergy".

Not all field types (e.g., date?) are supported, mostly because we haven't written field conditions for every data type -- what field type are you interested in writing a rule for?

It's also not possible to trigger a rule based on the change in a field's value, only on the new field value. That is: you can write a rule that triggers when dropdown field "X" is set to value "Y", but not a rule that triggers when it is changed from any value to any other value, nor a rule that triggers when it is changed from value "A" to value "B" specifically. Are these the kind of rules you want to write? What sorts of rules are you interested in implementing?

(From T655, select dropdowns aren't actually supported at the moment, but the same idea applies to supported fields like a text field.)

Here's our concrete use case:

• We want to enforce classifications of tasks at a high level in "components" (iOS, Android, Server, PR, Marketing...) and "types" (Task, Bug, Feature...).
• I created 2 "select" custom fields which work fine (and are searchable)
• We need to have a default assignee per component: my solution was to use a Herald rule for that: if task has component X, and assignee is empty, set assignee to Y

Since this rule would use the component custom field as a condition, it should work fine.

A more advanced use case would be advanced task routing based on changing the status like we had at Apple with Radar e.g. if status changes to "build", change assignee to person who does building, if status changes to "verify" after build is done and released, change assignee back to originator and set tag of build in task metadata. But based on your comment "It's also not possible to trigger a rule based on the change in a field's value", I guess that's not an option.

I guess this task should be renamed "Allow Herald rules for Maniphest to use custom task fields as conditions". But at this point, it becomes a dup of T655, so maybe this ticket should just be focused on adding support for "select" type custom fields as condition, which hopefully is not complex to implement. That would be really really nice to have for us.

Side questions: would either described cases above be implementable using custom event observers? And if so, do you know of a starting point?

Like T5015, exposing select fields to Herald is mostly blocked by T4420, and then UI issue (it's messy to generate arbitrary typeaheads right now).

We've generally moved away from events for this kind of thing because almost installs found them very hard to write and maintain, and most of the things they could do are now handled by Herald (the next most common set of use cases is handled or will soon be handled by Harbormaster). We've made them a bit easier to install than they used to be, at least, but Herald is way easier for us to maintain and seems to be a lot easier for users to write rules in, so I'd rather make Herald powerful enough to do these things than push you toward events.

I think you'll be able to write fully custom Herald actions and conditions soon-ish too (see D8784 for actions, conditions are probably further out), which could let you kind of fake things here, e.g. "When: [always] Take action: [run my arbitrary custom thing full of ad-hoc code]". This is probably slightly better from a maintainability point of view than events, since it's at least a little more structured.

I can only agree, it would be much better to have everything in Herald. We'll give it a shot with an event observer until these features land.

@epriestley so maybe this isn't the right place to leave this comment (let me know if I should create a new task?) but I'm finding this is acting in a way that seems a bit inconsistent. In particular, I added a new boolean custom field --

in Herald, I can create a Herald rule that *triggers* on the custom field, but I can't create a Herald rule that *changes* the value of the custom field. But we have other custom fields in our installation that *can* be changed with Herald rules. Is this a specific limitation to boolean custom fields or something like that?

(In case you're curious about the use case, we want to track whether specific tasks are bugs that are affecting external users. There are some projects where by definition *all* tasks are bugs that are affecting external users, so I want to automatically set this field to true if certain projects are applied to the bug.)

The best place for this kind of question is now your organization's support pact -- @tammybutow or @alexmv should be able to help you get access.

There's no upstream support for changing the value of any custom field via Herald, so if you're seeing it on your install I can only imagine that maybe it's an extension someone at your organization has written.

The only real way to do this with upstream actions today is to use a project tag instead of a custom field: create a project like "External Impact" and use that to tag tasks with external impact, instead of a separate field.

We can add upstream support for modifying custom fields, but you should file this request through the support pact if you'd like to see it implemented.