Make your first workflow a useful one.

A practical way to choose the job, start read-only and check the result against your software.

5 min read · Updated 25 October 2026

Pick one question, not the entire business

A first workflow should be narrow enough to check. “Show stock on hand for this product by warehouse” is easier to validate than “optimise our whole inventory”. Choose a question with a known record and a person who can confirm the answer.

Write down what a good result looks like. Which product, project, customer or order should be included? Which account owns it? What date or status matters?

Check the connector status first

Read the connector’s requirements and verification notes. A documented API operation, a tool visible in an assistant and a live-tested business workflow are different kinds of evidence.

Unleashed access is by invitation from the waitlist, with live business workflows awaiting validation. Procore is in development and needs the applicable provider approval and live acceptance. Plan your first test around that status.

Start read-only

Use the minimum access the test needs. Read-only tools let you explore the records and the assistant’s interpretation before considering operations that change the source system.

Use clear identifiers when names could be ambiguous. Ask the assistant to identify the records and explain where its answer comes from. Compare the returned information with the source application.

Check the awkward cases

Try a record that does not exist, a filter that matches nothing and a request outside the granted permissions. A useful connection needs understandable failures as well as successful answers.

Check whether a result is complete. Pagination, account scope, permissions and provider limits can all affect what is returned. “I found three” is not always the same as “there are three”.

Introduce changes deliberately

Before enabling writes, agree the exact action, its consequences and who can authorise it. Validate the workflow in a scope appropriate to the business, including its failure behaviour.

If a change has an uncertain outcome, reconcile it in the source system before replaying it. MCP XYZ records operation intent and outcome and does not automatically retry ambiguous mutating requests.

Keep a short working record

Record the account, permitted operations, example request and verified outcome. Include the limits you found and who will own the connection. This gives the next person something better than “it worked once”.

Jiffi can help you choose the workflow, configure access and work through validation within an agreed service scope.

Connector status and permissions matter. Our examples describe intended workflows, not a claim that live provider business acceptance is complete.

Find your software
Talk it through with Jiffi