In Edge, there are two interesting aspects to Faults - Raising them, or Handling them.
You wrote: “I need to define the condition(s) and anytime flow matches with that condition and control will enter into Error Flow.” I think your statement refers to raising faults explicitly, with the RaiseFault policy. For example you could raise a fault if an incorrect content-type is passed in, with a POST request. This might look like this:
<Step>
<Name>RaiseFault-1</Name>
<Condition>Not (request.content-type =| "application/json")</Condition>
</Step>
Or you could explicitly Raise a Fault when the inbound request uses a malformed ID in the url path. This would look the same as the above, except it would use a different condition. Then int he RaiseFault policy, you can specify the response status code , the response payload, and the response headers. It’s nice to be able to explicitly raise faults based on conditions in the flow.
In Apigee Edge, the built policies can implicitly raise faults, as for example with VerifyApiKey, or AccessControl. Faults can also occur when backend systems fail to respond, or respond with 400 or 500 errors.
In any of these cases, whether you explicitly raise a fault with RaiseFault, or if a Fault occurs due to some other occurrence, the processing of the message enters “fault flow”. And at this point you can use FaultRules to handle the faults. This is all described in the documentation I linked to above.
Within FaultRules, you do not normally raise new faults. You would not use RaiseFault, normally, within a FaultRules section. There’s already a fault, so no need to raise one. Instead, you have the opportunity to adjust the fault message, which i think is exactly what you asked about.
Within a FaultRules sequence, you can use AssignMessage, or a JS policy, to modify the response payload, or the status code, etc.
Does that cover what you want to do?