This article helps you find out why Pipeline Assistant is not doing what you expect. Find the symptom in the sections below and follow the checks in order. For how rules work, see Pipeline Assistant. Most fixes need a Cinode administrator, because rules are edited on the Rules page of the configuration wizard in Cinode Flows.

Pipeline Assistant has no other way to deliver messages, so notifications are skipped until the Chat Agent is set up and connected for your Slack or Microsoft Teams workspace. On the Rules page, the "Send notification" action is then labelled as unavailable because no chat integration is connected. The rule is still saved and starts working once the Chat Agent is connected. Rules that move a project or change its status do not depend on the Chat Agent. See Chat Agent: Admin setup.

Pipeline Assistant does nothing until you add rules. The weekly digest and the nightly check only run when you have rules that use them. Open the Rules page and check that you have a notification rule for the stage you expect.

When a rule works for others but not for one person, check these causes:

The "A channel" option appears only when the Chat Agent is connected and at least one channel can be listed. At present the channel list is available for Slack workspaces only. It shows only the channels that the Chat Agent has already been added to, so add the Chat Agent to the channel first. Private channels are marked "(private)".

A rule with an incomplete or invalid setting is skipped when Pipeline Assistant runs, and the other rules keep working. There is no error in chat, so a rule can look saved but never run. Check the rule against this list:

Also remember what each trigger covers. "Project is updated", "enters the stage", "inactive for N days" and role rules apply to open projects only. Only "status changes" applies to projects that are Won, Lost, Abandoned or Suspended. A project that has been set to Won is no longer checked by role or update rules.

This usually comes from the way conditions match. Completeness conditions such as "Deal value missing or too low" and "Roles not assigned" match when something is wrong. Scope conditions such as "Team is" and "Project status is", and "Roles staffed", match when something is true. Read the condition name as a description of the situation you want to catch. All conditions must match together. There is no "or".

Deal value, contract value and probability are floors. They flag values that are too low and never too high. A deal value of exactly the minimum also matches, because the value must be greater than the minimum.

That is expected. The role trigger fires when a role is created, assigned, booked or changed, when a person is assigned or removed, and when a preliminary booking is added, removed or changed. Deleting a role does not trigger rules.

Stale-deal reminders are sent once per project, when the project first crosses the limit. The reminder is not sent again until someone works on the project, and it then goes quiet again. A reminder that could not be delivered is retried on later nights. The weekly digest recaps stale deals that still have open items.

Reminders are once per project, not once per rule. If two inactivity notification rules match the same project, only the first rule's reminder is sent in a nightly run, and the second one does not send after it. Use one rule per stage, or give the rules different stages.

Check these points:

The digest runs every Monday at 09:00 in Europe/Stockholm time. It is sent only to recipients who have projects with open items, and only for notification rules that use the "project is updated" or "inactive for N days" trigger on open projects. It does not include rules with the "status changes", "enters the stage" or role triggers. If you have no such rule, or nothing is outstanding, nothing is sent. The schedule is fixed. You cannot change the time.

If a digest completed in the last 30 minutes, a second run is skipped so nobody receives it twice. Try again after 30 minutes.

When a rule moves a project to another stage, your "enters the stage" rules for the new stage run as well, up to 5 moves in a row. Status-change rules run after a status change made from chat or by a role rule, but not after a status change made by a nightly rule or an "enters the stage" rule. A chain of rules can therefore move a project more than once from a single change. Check the rules on the stages involved. To see what a rule would act on before you let it change projects, first build the same conditions as a notification rule.

A revert does nothing when there is no earlier stage or status to return to.

By default, Pipeline Assistant ignores updates that its own changes caused, and runs the follow-up rules itself in a controlled chain. The setting Process Self-Triggered Events on the Connections page turns that protection off. If rules are triggering each other repeatedly, make sure the setting is off.

If the Chat Agent says it could not move a project or set a status, check that the project and stage names are correct, that the stage exists, and that you are a manager. Moving, setting a status, undoing and running the digest need the Company manager access level or higher. See Pipeline Assistant: Use it from chat.

If the checks above do not explain it, contact Cinode Support. Include the name of the rule, the project, the stage, the time you expected the message and the Slack or Teams address of the person who should have received it.