• Stickiness is defined at the Work Queue level. When a case times out of a sticky queue and lands in your reassignment queue (no stickiness), it’s treated like a fresh assignment unless you explicitly change ownership/fields with rules.
• Sprinklr’s Rule Engine supports multiple rule types and triggers (e.g., Queue Rules vs Case Update Rules). Getting the right trigger and the right execution order is key; otherwise, only one of your rules will appear in the activity trail — the one that actually fired. 
• Case Update vs Queue Rule: A Queue Rule will trigger when a case enters a queue; a Case Update Rule will trigger when a case is updated (e.g., assigned). Choosing the correct context prevents “rule overlap” and hidden conflicts. 

1) Is it possible to trigger multiple rules on assignment from a queue?

Yes. Multiple rules can fire on the same event if their conditions are met and they’re allowed to run in sequence. In practice, you’ll want to control execution priority/order (via rule configuration) and avoid two rules writing to the same field at the same moment. Use one rule to clear and another to populate — but make sure their triggers don’t collide and their conditions chain logically.

2) Does having multiple rules that change the same field cause issues?

It can. If two rules write to Case Owner in the same transaction, whichever runs last wins. To prevent this, separate responsibilities by trigger (Queue vs Case Update) and condition (e.g., “only if Case Owner is empty”).

Recommended pattern (tested approach)

Goal: When a case enters the Reassignment (no stickiness) queue, clear Case Owner, and when it gets assigned from that queue, set Case Owner to the new Assignee.

1. Queue Rule — on entry to the Reassignment queue

   • Trigger: Message/Case enters queue = Reassignment
   • Condition: Case originated from a sticky queue OR Case has Preferred Agent/stickiness metadata (as applicable to your setup).
   • Action: Clear Case Owner (set to null).
   • Rationale: This ensures ownership isn’t “sticky” anymore once the case is in the non‑sticky queue.

2. Case Update Rule — on assignment from the Reassignment queue

   • Trigger/Context: Case Update (assignment event).
   • Condition: Queue = Reassignment AND Case Owner is empty.
   • Action: Set Case Owner = Assignee.
   • Rationale: Now that someone has taken the case, ownership reflects the new assignee without fighting the first rule.

3. Execution order tips

   • Place the Queue Rule earlier in the flow so it runs before your assignment-related Case Update Rule.
   • In Rule Engine, use the rule’s execution/priority settings (batch/order) to ensure the clear happens first, then the update.

Why your “clear on assignment” rule didn’t show in the activity trail

Common causes when a rule doesn’t appear:

• Wrong context/trigger: A Case Update rule set to trigger on assignment will not fire if the system considers the event as a Queue transition instead. Try moving the “clear owner” to a Queue Rule (on entry to the Reassignment queue), then keep the “set owner” as a Case Update rule.
• Condition not met: If your clear rule had a condition (e.g., queue name mismatch, owner not empty/empty logic inverted), it may simply have been skipped. The trail only logs rules that execute. 
• Field write conflict: Another rule (or queue setting) updated ownership after your clear, so the clear either didn’t run or got overwritten. Separating triggers and ordering avoids this. 

Quick checklist to implement

• Convert your “clear Case Owner” rule to a Queue Rule firing on entry to the Reassignment queue.
• Keep your “set Case Owner = Assignee” rule as a Case Update Rule with condition Owner is empty. 
• Verify queue names and conditions exactly match (string, case).
• Set rule execution order so Clear runs before Set. 
• Re-test and confirm both rules appear in the activity trail when their conditions are met.

Hope this helps!  LMK if you need additional info!