FlowRunner
PricingContact
Theme
Start Free

Powerlink (Fireberry)

CRM

Connect AI agents to Powerlink (now branded Fireberry), an Israeli CRM with a generic record model. Agents create accounts, contacts, and opportunities, read and write any object through generic record operations by system name, run queries, and inspect metadata.

23 actions API key available
A scheduled sweep or an upstream flow hands the agent a set of records to reconcile
Get Objects resolves the object's system name and numeric type code for this account
Get Object Fields and Get Picklist Values read the fields and the numeric codes behind every dropdown
Query Records (v3) pulls the current state of the target set with an `isLastPage` flag to page cleanly
Every picklist value in the payload is checked against a real code rather than a label
The CRM owner is shown the object, the field, the code mapping, and how many records would change
A person confirms the picklist mapping before Batch Update Records runs, because there is no batch undo

What This Integration Enables

Powerlink, now branded Fireberry, does not model a CRM as a fixed set of objects. Every record belongs to an object identified by a system name such as account, contact, opportunity, or task, and by a numeric object type code, and a custom object the business created last year is addressed exactly the same way as one that shipped with the product. This connector is built to that grain rather than around it. There are typed convenience actions for the objects most flows touch, and underneath them a generic record surface that reaches anything in the account, which is the honest way to integrate with a platform whose real object model is decided by the customer rather than by the vendor.

It is worth being precise about how those two layers divide, because the typed actions are deliberately not symmetric. Accounts have the full set: List Accounts, Get Account, Create Account, Update Account, Delete Account. Contacts have List Contacts, Get Contact, and Create Contact. Opportunities have Create Opportunity and tasks have Create Task. Updating or deleting a contact, an opportunity, a task, or any custom object is done through Update Record and Delete Record addressed by the object's system name, which works identically and is the same call the typed action makes. Reading is where you choose the right tool. The record list, Get Related Records, and the legacy Query Records endpoint cap page size at 50 and page number at 10, which is a hard ceiling of 500 records, so anything larger belongs on Query Records (v3), which allows a page size of 1 to 500 and returns an isLastPage flag. The legacy filter syntax is a string of parenthesized statements in the form (field operator value) joined with AND or OR, for example ((accountname start-with 'Bob') AND (statuscode = 6)), with operators including =, !=, >, <, >=, <=, is-null, is-not-null, start-with, and end-with. The v3 query supports aggregation, where SUM, COUNT, MIN, and MAX require a Group By and every Order By field must also appear in Group By, and without a Group By the query returns individual records. Two details decide whether writes land correctly. Individual records are addressed by a 36 character GUID while metadata endpoints address an object by its numeric type code, and picklist fields are set with their numeric code rather than their label, which is what Get Picklist Values is for. Authentication uses your Fireberry system TokenID, sent in a tokenid header on record and query calls and as a tokenid query parameter on the metadata calls, and the token determines which user account and permissions apply to every request. Batch operations run against a single object at a time, are not available on all Fireberry licenses, and there is no batch delete because the vendor does not publish its request path. Some endpoints return HTTP 200 with { "success": false, "message": ... } on a logical failure, and this connector inspects success and raises the message so an automation exception surfaces as an exception rather than as a quiet success. This connector ships no triggers and registers no webhook subscription, so change detection is a scheduled Query Records (v3) call filtered on a modification field.

Without FlowRunner

Custom objects are invisible to automation The objects a business actually added are the ones every generic integration ignores
Dropdowns are written by label A status is sent as text, the API expects a numeric code, and the record ends up in the wrong state
Bulk edits are one-way bets A wide update runs, the result is wrong, and there is no batch operation to put it back

With FlowRunner

The object model is read, not assumed Get Objects, Get Object Fields, and Get Picklist Values describe this account before anything is written to it
Codes are resolved before they are sent Picklist fields are set with the numeric value the account uses, resolved live rather than hardcoded
Wide changes are approved first The count, the object, and the code mapping are confirmed by a person before a batch runs

Use Case Scenarios

Inbound leads landing on the object the business actually uses

A website form or a campaign list produces new prospects. Before writing anything the agent calls Get Objects to confirm the system name and numeric type code of the object this account uses for prospects, which in some Fireberry accounts is account and in others is a custom object the sales team defined. Get Object Fields returns the fields that object actually carries, including the ones added after the last integration was built, and Get Picklist Values maps every dropdown to its numeric code. Query Records is then run with a filter such as ((accountname start-with 'North') AND (statuscode = 6)) to check for an existing record, and Create Account or Create Record writes the new one with picklist fields carrying codes rather than labels. Create Task schedules the first follow-up against the resolved owner, and Gmail notifies that owner with the record link.

A pipeline digest built with aggregation instead of extraction

A sales director wants the weekly numbers without a spreadsheet job that pulls the whole CRM. The agent uses Query Records (v3) with a Group By on owner and stage and a SUM over the value field, remembering that every Order By field has to appear in Group By and that omitting Group By returns individual records rather than totals. It pages with a page size inside the 1 to 500 range until isLastPage is true, rather than assuming one response is the whole answer. For the deals that need detail it calls Get Record on the 36 character GUID and Get Related Records to pull the contacts and tasks attached to each. The summary posts to Slack and the detail rows append to Google Sheets. Nothing in this scenario writes, which is what makes it safe to schedule.

A migration or enrichment that respects the account's own field definitions

A business is loading records from a legacy system or enriching an existing set from a data provider. The agent starts with Get Objects and Get Object Fields so the payload is built from this account's field definitions rather than a mapping file someone wrote a year ago, and Get Picklist Values so every status, type, and category is sent as the code the account uses. Batch Create Records loads the new records one object at a time, since batch operations do not span objects and are not available on every Fireberry license. Where existing records need correcting, Batch Update Records is prepared but not run, because there is no batch delete and no batch undo, and a wide update against a picklist field is one of the few operations here that is genuinely hard to reverse. That is where the gate below sits.

Human-in-Loop Highlight

Batch Update Records is the operation to gate on Fireberry, and the reason is a specific pairing rather than a general caution about bulk edits. Picklist fields are set with their numeric code, not their label, and the codes are configured per account. So an agent that sends statuscode: 6 because that was the code in the last account it worked in, or because a mapping file said so, does not get an error. It gets a successful batch, an HTTP 200, and several hundred records that now sit in a state the business did not intend. The reverse operation would be another full batch update, which means you need to know the correct prior value of every record you just overwrote, and this connector has no batch delete because the vendor does not publish the path, so there is no way to remove a bad batch create either. Batch operations also run against a single object at a time and are not available on every Fireberry license, so the failure often arrives partway through a multi object job. The agent therefore does the resolution work and stops before the write. It calls Get Objects and Get Object Fields for the target object, Get Picklist Values for every picklist field in the payload, and Query Records (v3) to count the affected set and read the current values, then posts to the CRM owner: "Batch Update Records is ready on object account, type code 1, for 863 records. It sets statuscode and accountcategory. Get Picklist Values returns 7 codes for statuscode on this account, and my source data maps to 4 of them: Active to 6, On Hold to 8, Churned to 11, and Renewal to a value with no code on this account, which affects 112 records. Current values would change on 741 records and stay the same on 122. There is no batch delete and no undo, so putting this back means another batch with the prior values, which I have captured and attached. Run it, run it without the 112, or hold?" The owner answers once, and the batch runs against a mapping a person confirmed. This is the human-in-the-loop moment on a CRM whose object model belongs to the customer, because an agent can read every code an account defines and only a person can say which business meaning each of them carries.

Agent processes routinely
Detects exception requiring judgment
Clear match Continues automatically
Ambiguous Routes to human via preferred channel
Human decides
Agent resumes with decision

Agent Capabilities

23 actions

Records

6
  • List Records Returns records for an object addressed by its system name, capped at a page size of 50 and a page number of 10. Use Query Records (v3) for anything larger.
  • Get Record Retrieves a single record by its 36 character GUID. Used to confirm current state before a change is composed.
  • Create Record Creates a record on any object, standard or custom, addressed by system name. Picklist fields are set with their numeric code, resolved through Get Picklist Values.
  • Update Record Updates a record by GUID on any object. This is also the update path for contacts, opportunities, tasks, and custom objects, which have no typed update action.
  • Delete Record Permanently removes a record with no undo. This is the delete path for every object that has no typed delete action.
  • Get Related Records Returns the records related to a given record, with the same page size cap of 50 and page number cap of 10 as the record list.

Queries

2
  • Query Records Runs the legacy query against an object's numeric type code, filtering with parenthesized statements in the form `(field operator value)` joined by `AND` or `OR`. Capped at a page size of 50 and a page number of 10.
  • Query Records (v3) Runs the v3 query with a page size of 1 to 500 and an `isLastPage` flag for clean paging, plus aggregation through SUM, COUNT, MIN, and MAX. Aggregates require a Group By, and every Order By field must also appear in Group By.

Batch

2
  • Batch Create Records Creates many records against a single object in one call. Not available on all Fireberry licenses, and there is no batch delete to remove a batch that went in wrong.
  • Batch Update Records Updates many records against a single object in one call. There is no batch undo and no batch delete, which is why this action runs behind an approval on the picklist code mapping.

Accounts

5
  • List Accounts Returns account records with the standard record paging caps.
  • Get Account Retrieves a single account by GUID.
  • Create Account Creates an account record. Used at the top of a lead capture flow where the account object carries the prospect.
  • Update Account Updates an account record by GUID.
  • Delete Account Permanently removes an account with no undo.

Contacts, opportunities and tasks

5
  • List Contacts Returns contact records with the standard paging caps.
  • Get Contact Retrieves a single contact by GUID.
  • Create Contact Creates a contact record. Updating or deleting a contact goes through Update Record and Delete Record with the `contact` system name.
  • Create Opportunity Creates an opportunity record. As with contacts, later changes to an opportunity go through the generic record actions.
  • Create Task Creates a task, which is how a flow turns an event in another system into a concrete follow-up with an owner in Fireberry.

Metadata

3
  • Get Objects Returns the objects in this account with their system names and numeric type codes, including custom objects. This is the first call in any flow that intends to write.
  • Get Object Fields Returns the fields defined on an object for this account, so a payload is built from the running configuration rather than from documentation.
  • Get Picklist Values Returns the values and numeric codes for an object's picklist fields. Required, because picklist fields are set by code and the codes are configured per account.

Frequently Asked Questions

What can FlowRunner do with Powerlink (Fireberry)?

FlowRunner agents can run List Records, Get Record, and Create Record in Powerlink (Fireberry), plus 20 more actions.

Does connecting Powerlink (Fireberry) to FlowRunner require OAuth?

No. Powerlink (Fireberry) connects to FlowRunner with an API key, no OAuth flow required.

Can Powerlink (Fireberry) trigger a FlowRunner workflow automatically?

Powerlink (Fireberry) doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with Powerlink (Fireberry)

$100 in credits. No card required. Connect in minutes.