Objections versus corrections in applicant responses
Date: 2025-07-29
Transcript
different things. I think an objection would actually be initiated by the applicant where we make a comment and they have an objection to our comment. Oh, okay. So I think that's kind of where I'm seeing this idea of objections versus corrections. So I think the idea is that we can have a we have our corrections that are provided to the applicant
the applicant wants to object to a certain correction, basically say, hey, we don't need to provide that, right? The current process is they just have to write that in the response to corrections and say, hey, you don't do that. I think the idea of this is we want to have the ability where that's actually documented in the system, that objection is documented in the system, and then if we go back to the previous page, then that requirement
um on page 11 of the slide was there an objection this one yeah that one I'm not sure about that self-certified kind of throws a wrench in that so yeah that's what I was thinking about yeah um but let's say that the the
they have an issue with that correction that that's the kind of the process for them to escalate, right? Bring that up to the plan checker and the plan checker then they can that so basically highlights it to the plan checker because I think right now sometimes what happens at least at the counter is sometimes the customer says no we don't need to provide that and the plan checker just responds with the exact same correction.
And so there's no back and forth. It's just, it is what it is. So I think the idea behind objections is that if there's a specific correction that the customer wants to say, no, we don't need to provide that. I have an objection to that correction. Then we can say sustained or overruled. I think that's where that's coming in.
and then we can update we either enter an update or provide a note for it right say no is no this is required you know do that so I think that's the idea behind that yeah okay um trying to think what the best sort of path forward is for that would we want to allow the applicant then when they are responding to comments to
I'm trying to think of that also.
I'm going to have to think on that a little bit. Anyone else have an idea about that? On how a customer can raise objections to a specific comment. We don't want to just say objections in general to all the comments because that's going to get too broad and it's going to be crazy. But yeah, Sammy. Going back to the columns where they have to respond, can we add a third column
and have that as an objection column where if they don't have a response, they can object, I guess, over there. We could. I mean, if we give them a box to respond, they're either going to, you know, fix it or they're going to object, right? I mean, that's kind of like they only have so many options.
I think the concern with allowing the customer to flag it as an objection is that it might sort of encourage more objections than we want and those still have to then be reviewed in any case um
because if they have something that they're not addressing and they forget to flag an objection or the opposite, somebody would still need to review all of those. I was wondering if we could perhaps use the comment status for that and have the plan checker flag those comments as objections. Then maybe we'll have some workflow that is related to that.
We do have a comment status field. So in addition to approved and rejected, we could have objection. This might be one that we need to come back to.
might be one to come back to because the whole idea of objections is kind of like when we were talking about appeals, right? We don't want to make it too easy for the customer to file an appeal because then we're going to be just a deluge of appeals. So we want to make sure that we don't go too crazy with this. It might just be responsive corrections
the comment for the response to corrections is I object or I don't want this. So that's something that, and then the plan checker can flag it and say, oh, that's an objection. I need to bring this to my supervisor type of thing. Yeah. Yeah. So, okay. You can take that away and think about what you would want this to potentially look like. We will also in the meeting session later be talking about sort of some related functionality that exists on the meeting platform.
on the event object in Salesforce. So that might also give you some ideas. So we'll come back to this one. System-sharp DB is to generate standardized plan check checklist based on various application criteria characteristics. This is where we're coming back to the sort of idea, perhaps, of a checklist as a series of tasks or something like that. And
Like I said already, I have some hesitation around this in terms of exactly what would be included and how we would present those to the user. We don't want really for somebody to have hundreds and hundreds of tasks to complete because then things that are actually a priority are potentially going to get lost.
But I think it might be challenging to do, you know, given that people have different ability levels, different specialties and things like that. So what I was envisioning with this one is, you know, we have, for instance, for building plan check, we have a science correction list, right? And so if someone is reviewing a...
Jassy, Ammu, Fez, Shama
a plan checker is reviewing a um a plan check for signs let's say and we know the type of application is signed that we can actually go in and say okay by default they get the plan check correction list and they can check with you know so essentially creating um
being able to designate this type of correction applies to signs, right? And then when the plan checker is reviewing the plans, they can actually go into OCPS and then checkbox the ones that apply. Does that make sense? It does. Is that... I haven't actually looked at a checklist at the correction documents for a while. There's an additional sort of
Context, right? So it's not just a checkbox. You have to provide additional context in terms of what specifically we're asking to be corrected. Is that right? Yeah, and there's standardized language that we've actually gone through to make sure. So what I'll do is I'll share my screen real quick just to show you. Let me just arrange my windows so it makes sense. Let me do share my screen. Present.
so for example this is the ones for signs right and we have standard instructions which is pretty straightforward and then we get into things like review the clearance summary worksheets look at the sign management there's like documents that we think that they should read right and then we get into general requirements permit application provide a plot plan provide the you know legal description on the plans yada yada yada right administrative
zoning requirements, building requirements, different type of things like projecting signs. So these corrections are essentially what our staff does is if the applicant's applying for a roof sign, let's say, we go to section H and we circle the items that need to be corrected. Oh, you didn't provide this guy right here. So I'm going to circle this correction and the customer knows that that's the case now.
That's a very manual process, right? I actually have to download this file, I have to circle it. So what would be nice, and I think what this requirement is asking for, is for this information to be ingested into the system at some point.
And then the plan checker can, when they get a plan check for signs, they can select this and then select, I want to make sure, you know, correction C1 applies. Incorporate all comments modeled from the set of plans, right? I want to make sure that B1 applies, right? Information signs. So I think that's the idea behind this requirement is that, you know, we have with LA EBS, we have a ton of these correction lists.
are going to hear. Yeah, I've seen this. Yeah, we have a whole bunch. We have like the single family duplex one. And then we get into supplemental ones. So like, for example, a supplemental one, the baseline hillside ordinance. Actually, that's another one. A structural, this is actually, this is BHO. So this is the zoning one, basically. Talking about the zoning of the BHO and how that applies to
So these type of correction lists we want to be able to generate in the system, not just here's a PDF that we circled. Does that make sense? It does, yeah. So the customer will be using this as well, right? They would be expected to review this document first.
before submitting anything so that they know what sort of things to avoid? Ideally, that's what they do, but that's not a requirement. Right, okay. I'm just wondering sort of if your thought would be having a list of items in the system based on the permit type or the two requirements are basically based on the plan type and other attributes of the application.
Would that be just a sort of checklist? Here's the things that apply. Maybe you have a note that goes along with that. And then everything else that is currently on that form is no longer there. Because I see there's various diagrams and things. There's spaces to fill in different values and things like that. Yeah, but let's say if the customer complies with that correction, let's say the requirements of FIFO setback and they already have a FIFO setback,
then we don't circle it and it doesn't show up right yeah I was more asking like if we think that just having that sort of list could replace some of the other things that are included in that form like the diagrams and things like that really because anytime we get into trying to reproduce diagrams and things it's going to get very complicated very quickly so if we can sort of yeah
I think if there's a diagram, then what we would probably have to do is have a link to an image within the correction. Or the ability to link to an image. So we can then create an image, create a link to it somewhere, either ledbs.org or some sort of link. And then when the customer is presented with that specific correction, it says, with this diagram, and then they click on the diagram and it pops up a link to the image.
Does that make sense? Yeah. And how often do these direction sheets change? Fairly often. So we would need to also have the ability from a supervisor or a super user standpoint to be able to go in and add or remove items or modify items from the list of standard corrections. Yeah. Okay.
because every three years the code updates and then the building code updates every three years and so do the electable and then on top of that there are ordinances that are added all the time or executive orders that are added all the time where we might need to. So this component of customized checklists kind of is not just a pick list for the plan checker to use but also something that a super user would have to have an interface for to edit. Okay.
There's definitely some potential complexity here in both of those two requirements and then potentially some of the related ones as well that talk about the checklists. I will take that away and see what the out-of-the-box checklist functionality can do in terms of those.
Okay. System shall be able to manually create a plan check task. I think this is more like the tasks that we already talked about, right? Yeah. Very different than a plan check checklist. Okay. I think this one is technically already possible if we're using the task functionality. Okay.
that might be another one that's sort of part of that same demo. Yeah, yeah. All right. Systems chart the ability to publish plan objections to a portal where multiple stakeholders can access and post comments. Yes, so this is another one that...
where I was a bit sort of confused about what an objection was. This sounds more like it would be something that's coming from the plan checker rather than from the customer. I think the intention of this is to replace the reliance on email for this. So right now, if someone has...
If a customer doesn't like our corrections, typically what they'll do is they'll email the plan checker and say, hey, I don't agree with this, this, or this, or they'll email the supervisor. And the problem with that is transparency. The plan checker, if they don't respond to your email right away or they're on vacation or whatever it might be,
No one else knows about that until it escalates to the next person and next person and next person. So I think the idea of this, this is the objection basically, right? I think the idea behind this is that we want to have an interface where there can be conversation between the applicant and the plan check staff that is divorced from email. There might be an email notification
but it's not reliant on email so that if I'm a supervisor and I go into a certain application, I can see the communication back and forth. And I think the various stakeholders would be the people that are the project sharing on the customer side. So that's what I'm thinking. So an authorized stakeholder is someone who has the authority to add comments on an application from the customer project side.
okay so let's say then that if we treat an objection as a type of comment or a status of a comment that we're flagging whether that's done by the applicant or done by plan checker doesn't really matter for this purpose I think that we can allow users who have project access to be able to submit comments what I'm not sure whether we can support though is the sort of
threading and people having a kind of ongoing discussion based on a single comment. So I wanted to make sure that that was kind of what we were talking about. It sounds like it is, so I will have to take a look and see sort of what the limitations are of that functionality because I think using the comment objecting clarity is a really good fit for this in general. It will
Threading could be an issue, right? Because if you have five different people on the app, you know, asking questions, and then I could see how that could be. I think of Google Chat right now, right? Where, you know, in our group chat for this project, right? We have threads, and then we have just the general response. So that's something we can look into. Yeah.
okay yeah so i'll take that away and see what the limitations are on the the object comment side um and then we can decide if that's a problem or not but i think in general comments are a good fit for this so if we can go down that path then i think that'll be good versus going towards something that's more kind of customized all right only a few more system shall have the ability to store categorized standardized plan check checklist tasks
based on various criteria. Okay, I think this sort of ties back to what we said before. So categorize based on the type of the permit application, essentially, right? Of the type of work that's being done. Yeah, yeah.
So I want to make sure that we separate these things here. So the checklist task is going to be more of the sort of
choose your own adventure correction sheet and the a task might be something that is let's say the plan check supervisor saying hey you need to follow up on on x or something like that um yeah so the the checklist is going to be more for the customer whereas the tasks is going to be more internal is that
align with what you're thinking? That's what I'm thinking also, yeah. So the tasks is something that we want to make sure that we, either the plan checker or the supervisor can say, hey, make sure these are completed before you approve this permit. Okay. Whereas the checklists are things we give to the customer, you know, fix this, fix that, or do this, do that. Okay. Yeah, the tasks side of that is...
I don't think is a problem. Like I said, I'll record a demo for it. The checklist part is probably going to be more complex, so we'll come back to that. I just wanted to make sure that we know which of these falls into which sort of bucket. Right. Systems should prevent a permit or record from advancing past the plan check stage until all associated plan check tasks have been successfully completed. Okay, so this is...
my sort of reverse engineering of assumptions that a plan check task would be equivalent to review just because that's how clarity works sort of out of boxes that typically wouldn't advance something out of the plan check phase until all of the reviews that are associated with that plan check have been approved and until then we keep going through cycles.
this is more sort of saying for each correction that we have it also needs to then have a status and until all of those corrections have been resolved we can't advance past the can't advance out of the fact check phase I'm hesitant to do that mainly because
mainly because it's a lot of extra manual work for our staff, right? If we're breaking it down that every single correction has to have an approved or denied status, that's going to be ridiculous. And it also opens us up to liability if there's ever a mistake made on the plans.
us actually advancing that status to a completed or whatever it would be. One, it's too tedious, and two, I don't think it's good in terms of liability. So I think what we're talking about in this case is if there's a task administered by the plan check staff or by the supervisor for the plan check to verify or complete before our ministry. So essentially, like...
making it an internal requirement, if that makes sense. Does that make sense? So when I'm envisioning tasks to be, which we discussed earlier, is either the plan checker or the supervisor can say, hey, before this permit is approved and issued, make sure these things happen, right? And then the plan checker or supervisor can then go through and checkbox that those things have happened.
and then have that be kind of a thing, almost like an internal checklist for the staff to make sure happens before they approve the permit. Make sure you have the plot plan, make sure you have this, make sure you have that. Some of them are gonna be standardized ones, but some of them are... So I'm thinking more like a red flag, like, hey, make sure you talk to...
there are times where it's like we want to remind ourselves hey make sure you update this before you issue the permit right update the structural inventory before you issue the permit right those are things that especially for counter we want to make sure that you know so like one example I'm thinking of right now is the structural inventory on an application sometimes we can't complete that
because the information is missing from the plans. So what we do is in the comment section of the permit, we say, hey, next plan checker, it could be someone else, it might not be me. Hey, next plan checker, be sure to update the inventory before you issue the permit, right? That type of thing would be very nice to have in a task that needs to be checked off and say, oh yes, I did double check that and it's updated before I issue the permit. Does that make sense? It does, yeah.
I'm also thinking, though, that we will, so this is essentially saying there are going to be tasks related to, let's say, an application that will block that application from advancing if they're not completed. And I would say specifically locking it from advancing to accepted or ready to issue or whatever the status is that we decide. Right. Yeah, that's a good distinction.
I think that we will also have to support tasks that do not block something. Yes, so I think we should have a task, like a required or not required, required for issuance and not required for issuance type
Yeah, or I think there might already be a type field on the task object that we can use. Okay, yeah, I just wanted to make that distinction, and we're talking about tasks in this case, and also that this is going to be internal, and yeah, we do want to hold up the advancing of the application in that one specific case. That makes sense.
Anyways, which one did we get to? Yeah, okay. System shall enable before and after corrections to be easily identified by the applicant to highlight the review comments and the corresponding corrections made. I wasn't sure if this was talking about plans because anything that's on the plans is sort of not controlled by clarity directly.
what we can do is show the track the page that a comment was made on and the type of the comment but like I said here there isn't really a way to force Bluebeam to use a particular style for comments or corrections or anything like that so I don't know if you would see this more as a sort of best practice for plan checkers or is this something else let me just show you this is the
how the comments look in Clarity. This is just some of the information that's passed on. So it shows you the type of the comment, who made it, and what page it's on. And then obviously this is the text of the comment. And this is out-of-the-box functionality with Blueprint integration? Yes.
I see. So this is a little different than what I was imagining. So this is actually good. I like this.
this is the data that we would usually use to drive that comment letter or to drive that sort of table of comments so you'd see going back to what we talked about earlier with the table layout the portal user would see this one column which is going to be the actual comment and then maybe some of this other information and then like the blank column for them to fill in their response I see yeah and if the plan changer like draws an arrow or something does that also show up here
No, it doesn't. It would only be for text comments. Only for text comments, okay. Okay, so this actually makes a lot more sense with the each comment needs to be resolved before permit issuance, right?
So this is tied to a particular submission, is that correct? Or how are these tied to the project? Are these comments added to the project? Are they added to the submission? How are these things linked to the actual project?
Yeah, it's a good question. So the comments are actually tied to the milestone by default. So when we go through that process of cycling the corrections, so the first cycle, second cycle, those would be different milestones. Within that milestone, there can be multiple files. So for example, if we had three different files, if we had three different plan documents, let's just say,
When you saw the list of comments for that milestone, you would have those different file names would be listed here, and then you'd have the page and the type as well. So it's at the milestone level. So when you cycle that, you get a whole new set of comments, but then we're still storing the previous comments on the previous milestone if we need to look at those as well.
Yeah, I still don't want to force the plan checker to go through and approve all these, right, every single milestone. That's just extra busy work we don't need. At the same time, though, it is I know one thing that we do for plan checks, it's kind of a best practices thing. It's kind of
Not everyone does it. Not everyone actually follows this practice. But what we've done in the past is when we make the initial correction, it's in red color in Gubi. And then when we kind of keep track of the corrections and when we approve it or when we say it's ready to go, we turn it to green.
And so basically, as we're going through the process, we're changing, we're basically saying, this has been addressed, this has been addressed, this has been addressed. Yeah. And then, yes, there is also the status field, which will track that status of the Bluebeam comment. When you click on a Bluebeam comment, you can, I forget what the exact statuses are. I can't remember if it's approved or rejected or something else. But you can actually flag that on the Bluebeam side. And that's done in Bluebeam, right? Yes.
So we could also do that to help differentiate on the clarity side. I don't think, though, that there's too much more that can be done on that without, like you said, getting into sort of somebody going through and manually flagging the comments, which I don't think is a good use of their time. So do you think it's acceptable to...
say we're meeting this by bringing over the status of that comment in Bluebeam. So as soon as you set it to approved or completed or whatever the status is on the Bluebeam side, that will update the comment on the Clarity side as well. So is that sufficient? Yeah, I think the EG callouts, I think that would, callouts slash color, I think that could be reviewed as status. Yeah. Okay.
good um all right last one and then I did want to spend a little bit of time on the um assignment stuff as well but I don't think we'll be able to get through all of that this has been very productive though so thank you everyone
and the system should provide a template for the applicant to respond to each comment issue to ensure each item is addressed individually to assess how the applicant has got the submission requirements. Okay, this is the same, I think, as the earlier one. I'm just going to go back to that. This is where we were talking about the table of comments and allowing people to sort of essentially respond in line. Do we think that that sort of approach will also meet this requirement?
I'm sorry, could you repeat that? Yeah, do we think that the approach of having a table for the comments? Yeah, the only part that I was questioning here is the system should provide a template. I'm not sure if the intent there is to say provide some templated text that they can use.
No, no, no. The template is what we discussed, the rows and columns, and one column being what your response is. Okay, perfect. Good. I just wanted to make sure that we were sort of aligned there. Yeah, this has been very good. I think we've got a couple of things that we need to follow up on. The only one that really sort of stands out to me as potentially complex is this whole checklists thing.
So I will do some digging on that. I will provide a quick video recording for people to look at of how the tasks functionality works. And I think we've got a couple of other action items as well. I am going to quickly look at some of these plan check assignment requirements as well. We do have a few more here, so maybe we'll come back to these later today.
All right. We did talk about this one, I think, before. I think maybe we talked about it even in the JIRA ticket review, but predefined service level overruns that trigger a notification to the supervisor or somebody else in the system.
Do we have any other examples aside from the initial corrections have to be responded within 30 days? Do we have other examples of where might be tracking a service level overload? These are at 15, right?
I personally don't know the definition of overrun in this case. Like the applications at a certain point, right? Or they pick something from a dropdown or something. Oh, oh. I'm reading it.
you know, like it's a Palisades permit. So we automatically notify staff or supervisors that a new Palisades permit came through. I honestly don't know anywhere where we do this. I was interpreting this more as we've exceeded a... A due date. Yeah, a due date. So I can't remember the abbreviation for it. But in the sort of support world, you would have like a...
deadline by which you have to respond to a customer email or something like that. And if you exceed that, the system will usually notify you to say, hey, you have an overdue message to respond to. So that's more what I was picturing. That being said, though, if we have a very small number of examples of this, that might change how we choose to implement it. So it is. Yeah, Jennifer.
yeah um according to the functional list requirement list it is actually associated with more of backlog management or overtime identification does that help so it's more it's more about
timelines for plan check, right? Yeah, a backlog, you know, you probably want to like, you have so many, a long list of backlogs and then you want to allocate over time for staff to address that to make it, you know, something like that. Are we thinking more size of the backlog or the sort of age of items in the backlog or?
either? Typically age of items in the backlog. So there's a couple of things that I would want to have an automatic notification on. One would be the backlog. Very, very important. Yep. Another would actually be when a project is assigned to a staff for review, depending on the type of review and the size of the review. So let's say that customer uploads for verification, right?
and then it's been a week and that verification has not been acted upon. I kind of want a notification saying, you know, I want the plan checker to have a notification saying, hey, a little nudge. Hey, this customer uploaded this a week ago. You need to act on it. So I think a predefined trigger, so that would be another type of overrun where we want to have the plan checker or the supervisor. So, and maybe have different triggers for different things. So maybe like
a couple days for the plan checker and then a week for the supervisor and that would be the type of thing that we would want to be able to configure to turn on and off per you know the supervisor can turn that on or off for specific employees or for specific items you know so kind of have this you know because yeah that's that's actually what I'm thinking in terms of that
Yeah, this is helpful. I think the original example we had, like I said, was the 30-day deadline for comments, but there are other examples out there, which is good. If you have any additional ones, now is a good time to provide those. Not right now, but at this point in the project. During the discovery phase. Yeah, yeah.
I don't think that we can support turning off those notifications for an individual user but we should be able to support sort of changing the sort of criteria so let's yeah yeah um or sort of you know turning those notifications so so okay and I think Greg brought up a really good one the the timelines will be different or the the notifications will be different based on uh so if a project is flagged as HSAP or affordable housing right
I would want to have a different flow or a different type of notifications for that or for Wildfire, Palisades Wildfire. They might have a more streamlined timeline or a more, they might have more notifications associated with them than other types of projects. Make sense? Yeah, yeah, I think what might be good then is in addition to sort of what these
should be for, so an item that's been in the backlog for a certain amount of time. We would also need the sort of criteria there, so I assume because the backlog is different sizes for building versus mechanical, let's say that that trigger will be different between the groups and then, like you said, other stuff as well, like programs. Yeah, as long as we know what those criteria are, I don't think that's a problem.
All right, you've probably got time maybe to get through the rest of the ones on this page. System shall allow staff to flag plan checks or watch or track through the entire review process. So have you seen the follow functionality in Salesforce? We had a brief demonstration of the follow functionality for an address. Yep. And it was...
I think the follow function is actually pretty sufficient for this, but we want to make sure we have a good understanding of what's being followed. Is it just the status, or is it when an opportunity happens, it goes out to a condition, or whatever it might be. I think we might need to have a little further discussion on what actually is followed when you follow something.
but I think the follow function or a slightly modified version of it would suffice. Yeah, okay. Maybe this is also something then that I need to record like a quick walkthrough of. Jennifer.
is the follow function out of the box does it allow the user to kind of like select an option of when to trigger the notification? Or what they want to follow. Yeah, I mean, the record they want to follow, right? But I'm sure it's also the notification will trigger by certain
Yes. Yeah. Right.
So no is the short answer to that. So the follow function is based on the record being updated and we track the record being updated based on the fields that are tracked for that record. So essentially when you follow a record, you're subscribing to the stream of changes for that record. When you go to look at your following records, you'll see the list of changes for that. So it's all or nothing? Yes.
Okay, thank you. Sorry, Tophar, I didn't mean to interrupt you. No, I think we were talking the same thing. Yeah, okay, so maybe I'll do the same thing there. I'll record a quick walkthrough and we can see if this is a good fit. All right. Systems shall be able to leverage information in the plan checker's profile to inform automated plan check assignment according to business rules configured in the system.
So this is where we get into some more of the specifics of the assignment service. We've talked about this before. We've got into some level of specifics, but we haven't got into a huge amount of detail here. So the short sort of answer to this is that there's a couple of ways that it's possible.
the first way is that the assignment service queue which would be the sort of set of records that are going to be assigned out to people can be based on whatever we want it can be based on the location and then that
Let's say the location of that record can be tied to a plan checker, which means that they will be one of the people who would be considered to be assigned to that record. It can also be based on their skills as well. So that's how we sort of would prevent somebody that is a building plan checker being assigned a mechanical plan check or one of the ways. So I think that that is the kind of thing that we're talking about in this requirement.
Does that sound accurate? Yes and no. I think one of the big things we were discussing in previous meetings was the idea of office groups. So, for example, we have metro backroom staff, right? Or metro backroom staff. There's four or five supervisors, 20-some plan checkers in that group.
and so we want the ability to assign plans for that group from the list of available plans right yeah and then we have a separate group in the same thing metro backroom but they're the high-rise group or they're the affordable housing group right and then similarly we have Van Nuys backroom and each of those have kind of a different staff that is actually assigning the plans
and so what we don't want is to have one assigned function that'll assign everyone. Does that make sense? Yeah, so I think that we would be able to support that. My first thought there is that normally the way this would work is that you would have an inspection or a review record
that would be associated to a region and then that region would determine who is eligible to be assigned the record. What we're talking about here is something slightly different in that the region is really like a combination of like a location and a group, which I think is fine.
Yeah, I think one of the other things that is worth noting or worth mentioning in that is that when it comes to regular plan check, so a normal regular plan check that's not affordable housing or not high-rise or whatever, right?
that could be assigned either to Manai staff or to Metro staff or to West LA staff. They do not need to necessarily be tied by region unless it's a paper plan. So the only ones that have to go to that specific office is paper plans. Anything submitted online or through ePlan, whatever you want to call it, through ICPS,
That could be divvied up however we want to. And that's actually how we manage with ePlan. That's how we manage differing supply and demand, right? If we have, let's say one week we have a ton of paper plans submitted in the Van Nuys office so that all the backroom staff are full of paper plans, then we just don't assign them ePlan. We give those plans to Metro office staff because...
they don't need, you know, they're already full up on paper plans. So I think there has to be some sort of ability for the system to draw from the same pool of plans, but when this plan check staff assigns the plans, they just pull the ones from a giant pool. Does that make sense? Yes. Yeah. So let me... I think this is the right...
we're almost at time so I'm just going to quickly show the mirror board yeah okay so what I think we are talking about here is in the assignment process in between here and when we're actually running the assignment service what we need to do is really just sort of pull in from the backlog the set of records
that we want to assign to a particular location and group. And then we will run the assignment service for that location and group. So let's say a supervisor would go through, look at the list, flag a bunch of records and say, okay, I'm pulling these into the group.
let's say the the backroom time check group for Metro downtown office for building and then update those records and then the view that they're actually running the assignment service from would be just those records so those would be the only ones that would be assigned and the only people that would be assigned them would be the people that have that
Region is what it's called in clarity speak, but that would really just be the combination of those attributes. Of office and type of project and so on and so forth. Yeah. Or type of group. So, yeah, I think that we could achieve that by sort of just adding an additional step in there. I'm trying to think if that creates any problems, but that's my first thought. Yeah, the only...
thing I can think of is if like let's say Van Nuys pulls the projects first right because they finished at noon that day versus 2 p.m. or whatever right so they're ready to assign it at 2 p.m. it'll pull the projects that are kind of next in the queue that are not earmarked for a specific location and then it'll try to auto assign them all right thanks Greg um
and then those, we just wanna make sure those don't get accidentally assigned to Metro at the same time, right? We don't have the dual thing. I think we can do that just for the status, right? Maybe like an assignment preview status where, well, we don't have to get into the actual design of it right now,
Yeah, I think we can do that. Yeah, I think this will work. We'll come back to some of the other assignment service items maybe later today if we have time after we've talked about the meetings functionality. We are at time, so I'm going to let everybody go.
Tags
#work