New member added to a Lark department → onboarding workflow
AnyCross connects Lark Contact, Lark Base, Lark Messenger, and group chat into a single triggered flow. The trigger is native: AnyCross has direct read access to Lark Contact events, so when a member joins a specific department the flow fires without a webhook or polling step.
Trigger: Member added to a specific Lark Contact department
Three actions: (a) Base row created, (b) personalised IM sent, (c) group chat membership added
Key questions answered: execution order, partial-success handling, whether IM sends when Base write fails
Access AnyCross at anycross.larksuite.com or through the AnyCross icon in the Lark app menu. If the icon is absent, confirm with the OctaFlow Lark admin that AnyCross is enabled on the tenant — it ships disabled on some configurations even when the pricing plan includes it.
Source: AnyCross Module Section 1 (Product Orientation) and Section 5 (Gotcha 5).
Execution order & partial-success
AnyCross executes actions sequentially in the order you place them in the workflow canvas. There is no native parallel execution. This matters for your partial-success question.
If the Base write fails, should the IM still send?
The answer is a design choice, and it has two legitimate answers depending on what matters more to you:
| Option | Behaviour | When to choose it |
|---|---|---|
| Hard-dependency chain (default sequential, no branch) | If the Base write fails, the flow halts and the IM does not send | When the Base record is a compliance or HR requirement — you would rather know the write failed than silently send an onboarding message with no audit trail behind it |
| Independent-action chain (conditional branch after Base write) | If the Base write fails, the flow continues and the IM sends anyway; the failure is logged | When the new member's first-day experience matters more than the Base record — a missed row can be fixed manually; a missed welcome message on Day 1 cannot |
The independent-action chain. The Base write failure is recoverable (Fran or the admin can add the row manually); a new hire who receives no welcome message on their first day is a worse outcome. The conditional branch approach also gives you visibility — you know the write failed — rather than silently halting without notifying anyone.
Independent-action chain with conditional branch
The workflow uses AnyCross's Conditional branch node to fork execution after the Base write attempt. One branch handles success (proceed to IM and group chat); the other handles failure (log the error and proceed to IM and group chat regardless).
The conditional branch feature must be available on the OctaFlow tenant tier — verify this before building. If it is unavailable, the simpler sequential flow (Option B) is the fallback.
Documentation links
larksuite.com↗ AnyCross template library (clone template 4 "New hire onboarding")
anycross.larksuite.com↗ AnyCross getting started (Lark Help Center)
larksuite.com↗
Before you build: pre-flight checks
- Confirm AnyCross is enabled on the OctaFlow tenant, so that you do not build a flow that cannot be activated.
- Confirm the Conditional branch feature is available on the tenant tier, because the partial-success design depends on it — if it is absent, use Option B instead.
- Confirm the AnyCross service account has member-write permission on the target Base table, so that the record creation action can execute without a silent permission failure.
- Confirm the group chat's chat ID is known (open the group in Lark Messenger → three-dot menu → Group Info → copy the chat ID), so that the add-to-group action has a valid target before the flow is activated.
Build the flow
- Open AnyCross and create a new workflow. Name it New department member → Onboarding. Clone template 4 (New hire onboarding) as your starting structure, so that the trigger and basic action skeleton are pre-wired and you only need to remap fields.
- Set the trigger to Lark Contact — Member added to department. Select the specific department this flow monitors, because without scoping the trigger to one department the flow fires for every department change across the whole tenant.
- Enable run history on this workflow at this point, so that any failure in this action produces a diagnosable log entry rather than a silent halt.
- Name → member display name from the trigger payload
- Email → member email from the trigger payload
- Department → department name from the trigger payload
- Join date → trigger timestamp (format as date)
- Add a Conditional branch node immediately after Action 1. Set the condition to: Action 1 status = Success. This creates two paths — the success path and the failure/other path, so that downstream actions can execute regardless of whether the Base write succeeded.
- On both branches (success and failure), add Action 2: Lark Messenger — Send direct message. Map the message to the new member's user ID from the trigger payload. Write the personalised message using the display name variable, because the display name is available from the trigger payload and using it makes the message feel addressed rather than generic. Example template: Hi {display_name}, welcome to the {department_name} team at OctaFlow. Here's what you need to know for Day 1: [link].
- On the failure branch only, before the IM action, add a Lark Messenger — Send group message action to a designated ops or HR channel. Map the message to: Base write failed for new member {display_name} ({email}) added to {department_name} on {join_date}. Manual row creation required. so that Fran or the admin is immediately aware of the failure without needing to check run history.
- On both branches, add Action 3: Lark Messenger — Add member to group chat. Use the chat ID from your pre-flight check. Map the member ID from the trigger payload, because the add-to-group action requires the member's internal Lark user ID (ou_ format), not their email — the trigger payload provides this directly.
- Save the workflow. Run a test trigger by adding a test user to the monitored department. Verify: the Base row appears, the IM is received, the group chat membership is updated, and the run history shows all three actions green.
- Activate the workflow, so that it begins responding to live department additions.
Gotchas
If the AnyCross service account lacks write permission on the Base table, Action 1 will fail without surfacing a visible error in the flow status — the conditional branch will route to the failure path, but if run history is not enabled you will not know why. Enable run history before activating. Verify permissions by executing one manual test record creation from the service account before the flow goes live.
Source: AnyCross Module Section 5, Gotcha 1.The member field in Lark Base requires an ou_ user ID, not a plain string or email. The trigger payload from the Contact event provides the ou_ ID directly — use it. If you attempt to write the email address into a member-type column, the field will be silently skipped and the row will appear incomplete.
Source: API Endpoints Module — member field encoding.Confirm that the "Add member to group chat" action is exposed by AnyCross on the OctaFlow tenant. The action list in AnyCross varies by tier. If it is not available, the fallback is to send the group chat's join link in the welcome DM and have the new member join manually.
Option B: sequential flow without conditional branch
Use this when conditional branching is unavailable on the tenant. The flow is: Trigger → Action 1 (Base write) → Action 2 (IM) → Action 3 (Add to group chat).
In this configuration, a Base write failure halts the flow at Action 1 and the IM does not send. This is the hard-dependency behaviour described above.
To reduce the cost of this failure mode
- Enable run history so failures appear in the AnyCross log.
- Set a Lark Base automation on the Onboarding table to DM Fran if no row is added within 10 minutes of a department join event — this provides a secondary alert path when the AnyCross flow halts.
- Accept that on rare Base write failures, the new member will need to be messaged manually.
At OctaFlow's scale, this option is workable but produces worse failure visibility than the conditional branch approach.
Handling partial-success across three connectors
AnyCross does not have a native rollback mechanism. If Action 1 succeeds (Base row created) and Action 3 fails (group chat add fails), the Base row exists but the group membership does not. AnyCross does not undo Action 1 in response to Action 3's failure.
The practical approach at this scale
- Log every failure. Run history captures the state of each action. When a partial success occurs, the run history tells you exactly which actions succeeded and which failed.
- Design for forward recovery, not rollback. Each action should be independently retryable. Adding a member to the group chat manually (if Action 3 fails) is a 30-second fix. Deleting a Base row (if you want to "roll back" Action 1) is also trivial at this scale. Design your ops procedure around "check run history weekly, fix any failures manually" rather than around automated rollback.
- Use the failure branch to alert. The conditional branch pattern above ensures that failures on Action 1 produce an immediate alert to a known channel. For Action 3 failures, add a second conditional branch after the group chat action that routes failures to the same ops channel.
- Sequence the actions in failure-cost order. The highest-cost failure is the one that leaves the new member without a welcome message. Sequence the IM before the group chat add — this way, even if the group chat add fails, the new member has been welcomed and the failure is a recoverable admin task.
Trigger → Action 1 (Base write, with conditional branch) → Action 2 (IM, on both branches) → Action 3 (Add to group chat, with its own error notification).
Account-manager escalation note
This is worth raising with the Lark account manager.
Function affected: HR (Fran) and all functions that onboard new team members
Lark gap: AnyCross conditional branch availability is tier-dependent; if unavailable on the OctaFlow tenant, partial-success handling across multi-action flows requires a workaround (sequential flow with manual recovery) rather than a native branch
Current workaround: Sequential flow with run history enabled; manual row creation when Base write fails; Base automation as secondary alert
Requested native fix: Confirm conditional branching is enabled on the OctaFlow AnyCross tier, or request tier upgrade if it is currently unavailable
The AnyCross module is at partial status. The Contact trigger (member added to department) and the three-action flow structure are documented in Lark's public AnyCross documentation. The specific conditional branch availability on the OctaFlow tenant has not been first-hand verified — confirm before building the full flow.