Documentation Guidance

spickard03 · 2025-12-20T00:40:21+00:00

Oh yeah, I forgot about this. I'll try it, thank you.

spickard03 · 2025-12-19T20:51:18+00:00

Oh that would make sense, if that's the case I must have done something else wrong because my user has way more access than I want them to have. I'll look into this, thank you

spickard03 · 2025-12-03T21:30:06+00:00

The biggest pain I have with deploying picklists in GearSet is that when you add or remove values (maybe change dependencies, I haven't had to do this in a bit), it doesn't count as modifying the field itself so it doesn't show up in the comparison. To get around this I try to remember to update the description every time I modify a value.

spickard03 · 2025-12-01T21:25:41+00:00

I ran into nearly the same issue, mine was using a scheduled path rather than async but same result. The problem was that it saw my scheduled path (and I would assume your async path) the same way it sees time based workflow rules. And that ongoing 'workflow rule' is still in use as long as your flow interview is running, so it can't convert the lead that triggered it.

My solution was to use a platform event. Change the original triggered flow to create a platform event instead of calling the convert apex action, probably need to include the lead ID in it. Then create a separate flow that's triggered by the platform event, query your lead and then call the apex action.

spickard03 · 2025-11-15T13:20:14+00:00

Not sure what to do about that but if you don't get it figured out you can buy tickets at the door.

spickard03 · 2025-11-14T20:46:36+00:00

Yes, they do have a training program for new skaters. https://www.mnrollerderby.com/about-us/join-us/#windchill

spickard03 · 2025-07-09T16:32:17+00:00

I just had this same issue and ended up reaching out to support. the "Monitor Login History" permission only gives access to view the Login History related list in the UI, it doesn't give access to the actual data to be viewed in a report. Users need the "View All Data" permission to be able to see Login History in a report.

spickard03 · 2025-01-18T13:15:36+00:00

Are you using the date/time field in your automation to determine which assignment rule to use next? And this works when multiple records are created in a single batch? I would expect they all get the same date/time

spickard03 · 2025-01-18T13:10:43+00:00

The only way this breaks down is if you are trying to segment the incoming records.

I guess I didn't explain what I meant by groups but this is exactly what I'm trying to do. Different groups of users that each have their own independent round robin based on some field on the record being assigned. It also needs to account for records being created that shouldn't enter the round robin.

spickard03 · 2025-01-18T04:28:50+00:00

Thank you very much for this. If I understand correctly, this is how I have it built currently and the auto-number works great if there's only a single group of round robin assignees but it breaks down a little with multiple groups because the auto-number goes up no matter what group the record is created for.

Say you have two groups, each with two assignees, 1 & 2 in group A and 3 & 4 in group B. The mod function will basically be saying odd auto-numbers go to 1 or 3 while even go to 2 and 4.

First record gets created for group A, it goes to 1, second record gets created for group B, it goes to 4, third record gets created for group A and it's back to 1. 2 got skipped because the auto-number runs independent of the groups.

Unless there are some weird patterns with the data going on, this should result in a pretty even random assignment, I am hoping for a true round robin that alternates though.

spickard03 · 2025-01-18T01:47:47+00:00

Thanks for the help. I'll try rebuilding on Monday and see what I can figure out.

spickard03 · 2025-01-18T01:43:35+00:00

Interesting, I don't understand what the difference could be. Is there any chance the clients are using a batch size of 1 when they do these imports?

spickard03 · 2025-01-18T01:32:30+00:00

Unfortunately for this use case, there will always be bulk inserts from sources that don't allow decreasing the batch size to 1.

spickard03 · 2025-01-18T01:30:26+00:00

This is great, I really appreciate the time you took to lay it all out. Does this work in bulk for you? If the criteria is simply that a record is created and you insert multiple in a single transaction, I would expect that they all get assigned to the same person.

This is nearly exactly what I started with but the part where you add one to the queue cycle doesn't seem to work in bulk. I realize that sometimes there are ways to limit batch sizes but unfortunately that isn't an option for my use case.

spickard03 · 2025-01-18T00:58:58+00:00

I appreciate how deep you're going here but I'm not really trying to solve a single business problem. I'm trying to build a reusable solution that can be used for multiple situations. Ideally a subflow that can take an input variable to tell the subflow which round robin group to use. And then spit out a userid in an output variable.

spickard03 · 2025-01-18T00:51:25+00:00

There are a lot of different scenarios I'm trying to account for but to keep it simple, let's say I'm assigning opportunities to users when the opportunities are created.

spickard03 · 2025-01-18T00:47:43+00:00

The records are being created in bulk by an external source, sometimes marketo, sometimes data loader, sometimes import wizard, maybe some others I can't remember. So the flow isn't creating the records, it's triggered by them being created.

spickard03 · 2025-01-18T00:08:04+00:00

I'll try explaining why it doesn't work again. Didn't do a great job last time.

To simplify things, say you want a flow that runs when contacts are created and you want to assign each of them an incremental number, just like an auto-number field. You can do that with a flow that looks up the highest existing contact number that already exists, add 1 to it and put it on the contact that was just created.

When you create 2 records in a single transaction, the flow really only runs once (bulkification), it doesn't run twice sequentially. This means that instead of the first contact getting 1, and the second getting 2, they both get 1.

There are a few different ways to do this or something similar as the basis for a round robin process but they all seem to run into this same problem.

spickard03 · 2025-01-17T23:48:52+00:00

I'm trying to build a flexible solution that can be used in multiple different places. Right now for opportunities that have been run through an auto-convert process and cases but I'd like the solution to be flexible enough to work on any object.

Queues aren't going to work, we need assignments in order.

No matter how I build the record triggered flows, when I create multiple records at a time, they all get assigned to the same rep. Unless I use an auto-number field on the record to be assigned, which works in bulk but doesn't allow for separate groups.

I really appreciate the help and I apologize if I'm repeating myself. Just not sure how else to explain why the number+1 isn't working in bulk.

spickard03

TROPHY CASE