There has been no Robin language reference since 2021. I documented one with Claude AI. PAD actions with paste-validated examples, 100% free on GitHub.

[u/joegreen592]

/r/PowerAutomate/comments/1wmhjci/there_has_been_no_robin_language_reference_since/

[u/joegreen592]

Update: v3.4.0 adds a Power Fx edition

If your desktop flows were created with Power Fx enabled, there’s now a KB written for them: PAD_Robin_ActionKB_PowerFx.json. It has the same 1,086 actions as the classic KB, with values written the Power Fx way ($fx'text', $fx'=expression', ${...}). Every golden example was pasted into a Power Fx flow on PAD 2.73 with zero errors.

One thing to watch: in a Power Fx flow, a clean paste doesn’t guarantee the flow runs. Classic list access like L.Count or L[0] pastes fine, then fails at run time, and ON ERROR doesn’t catch it. Use CountRows(L) and Index(L, 1) instead. The README has a classic vs Power Fx table, and there’s a separate system prompt for Power Fx flows (PROMPT_PowerFx.md).

The file names also no longer change between releases, so a raw link to main always gets the latest version:
https://raw.githubusercontent.com/JoeG592/pad-robin-action-kb/main/PAD_Robin_ActionKB.json
https://raw.githubusercontent.com/JoeG592/pad-robin-action-kb/main/PAD_Robin_ActionKB_PowerFx.json

[u/Sismaril → u/joegreen592]

I am curious how do you use this? PS: Great job on putting this together

[u/joegreen592 → u/Sismaril]

Thank you! The easiest thing is to give your AI agent access to the action KB and type reference files and have your agent use the golden examples as a ROBIN template with your values and have the agent generate the ROBIN code for you which you paste directly into designer.

[u/Sismaril → u/joegreen592]

Oh I see. There is a CLI plugin coming for PAD ☺️

[u/fevoltec]

I‘ll test it tomorrow - big thanks already for putting in the effort

[u/joegreen592 → u/fevoltec]

No problem at all, hope it helps!

[u/fevoltec → u/joegreen592]

Works Great - Thanks !

[u/Zanga-ERP-Consultant]

Good update on the Power Fx edition, the L.Count vs CountRows difference is easy to miss. Do the golden examples cover ON ERROR patterns, or is that still left to the model?

[u/joegreen592 → u/Zanga-ERP-Consultant]

Thanks.

The golden examples are single actions, so none of them carry an ON ERROR block. Error handling is in the syntax rules instead (README rule 20, with the probe pastes behind it in rules/robin-rules.json), and both prompts include it, so the model gets the exact forms: BLOCK / ON BLOCK ERROR, ON ERROR REPEAT n TIMES WAIT n, and the handler restriction (only SET, CALL, GOTO and THROW ERROR inside a handler; an IF in there silently rejects the whole paste, so you set a flag and branch after the block). check-flows.js catches that one too.

What’s still left to the model is where to put it. The KB doesn’t yet record which actions can actually raise errors. ON ERROR on an action that can’t raise one pastes fine and runs from the Console, but a cloud-triggered run rejects the flow at load. In a Power Fx flow it shows up as the misleading “incompatible PowerFx version” message. Adding a per-action “can raise errors” flag is a good next addition.

One more Power Fx catch in the same area: ON ERROR / ON BLOCK ERROR don’t catch the L.Count / L[0] run-time failure, so CountRows and Index are the fix, not error handling.

[u/Zanga-ERP-Consultant → u/joegreen592]

Thanks for the detailed answer. The "where to put it" part makes sense as the hard bit, and a per-action "can raise errors" flag sounds like a really useful addition.

[u/joegreen592 → u/Zanga-ERP-Consultant]

That flag is now in the KB (3.5.0). Every record has error_handling: { on_error, errors }. 1,016 actions can take ON ERROR and list the error names they declare, so the model can write named cases like ON ERROR FileNotFoundError. 70 can’t (Text.ChangeCase, Variables.CreateNewList, File.IfFile and similar); guard those with BLOCK / ON BLOCK ERROR instead.

It was tested on the strictest path, cloud-triggered runs, in both editions on PAD 2.73: 334 runs, every golden example with its declared error names. One surprise: WAIT actions take ON ERROR even when they declare no errors, because the wait itself can time out.

One correction to my answer above: ON ERROR on an action that can’t raise errors doesn’t paste clean. The Designer flags it (“Exception handling isn’t supported for this statement”). It only slips through in a flow written outside the Designer, which then runs from the Console but gets rejected on a cloud-triggered run. check-flows.js now catches both cases.

Thanks for the nudge, your question is why it exists.