51ºÚÁϲ»´òìÈ

Transcript

Hello everyone. Thank you for joining today’s session of 51ºÚÁϲ»´òìÈ’s customer support office hours. Today we’re going to talk about Workfront Proof Approval Reports. Just a couple of housekeeping items before we get started. Feel free to zoom in or out on your browser to accommodate the screen size, or you can drag the corners of the slide window if you want a larger view. We will also be switching between slides and a live demo. If the screen share portion doesn’t open automatically, there is a red media player icon with a play button at the bottom, and you can click that and it can pop open for you. I’ll make a mention of that later once we do the switch. We also have a Q&A chat box on the right-hand side of your screen, and we have a team of support engineers behind the scenes, ready to answer them as the presentation goes on, and we will follow up with any unanswered questions at the end of the webinar. Final comment, a link to this recording will be e-mailed in about 24 hours. Should you wish to view it again or share the link with your colleagues, everyone who has registered, even if you are not present today, if you registered, you will get the recording. With that said, I will hand it over to your presenter today. Chance, go ahead. All right. Awesome. Thanks everybody for joining. I see quite a few familiar names in the attendance list. It’s good to work with you guys again for those of you who haven’t got to work with. It’s nice to meet you. As noted, we’re going to be going over Workfront Proof Approval Reports. Just to highlight, this is for Workfront instances integrated with Proof accounts. This is a report that’s only available in the Workfront tool. If you’re on Proof standalone, this isn’t really going to be relevant to the view that can be created in that tool.

Just a quick bit about me. I’m Chance Brinson, Tier 3 with the Workfront support team. I’ve been with Workfront for about five years, supporting various areas of the product. I tend to lean towards specializing in the reports and custom forms slash cut data within Workfront. That’s probably where you’ve worked with me before if we worked on cases.

Just a quick overview. There’ll be a few key learning points. We’ll touch on functionality and usage, and then review some of the common pitfalls, which does cover some limitations as well as known issues that will come across with the report type, as well as how we can try and help to self-troubleshoot those. Just so you can either possibly resolve, if it’s a misunderstanding before, we get to reaching out to support or at the very least, gather all the helpful information that’s going to be needed for the support case to delve in. Then we’ll switch over to a quick live demo where we’ll go over building out a basic proof approval report where we’ll still use some advanced methodology with text mode as well.

Proof approval reports. Proof approval reports allow us to report on proof approvals set up on the documents and files proofed within Workfront. By the end of the presentation, you should have a better understanding of the following. What a proof of approval report is and what it isn’t, how to use this object and data to build reports relevant to your organization’s needs, and as well as identify and troubleshoot common issues and limitations coming up with this report type. Another quick disclaimer. As noted, we will be touching on some advanced example methods that require familiarity with the API and text mode. If you’re unfamiliar with that area as we’re going over it, I recommend revisiting the presentation after reviewing some of the documentation around report building and basic text mode along with the API Explorer. We’ll still be building some of the reports out in the UI in the example. I think everybody’s going to have an opportunity to take something away from the presentation, regardless of what level you’re likely at in reporting.

All right, so what is it? Well, we’ll start with the object itself. A proof approval object is created when a Workfront user is set to approve a proof, and it will be updated with relevant information as decisions are made. This means no object is created for those simply set to review the proof. The report itself is a historical record of all users set to approve the proof. This means that once created, the proof approval object will continue to exist. Reports set up with emphasis on filters are what are going to gear us towards usage in the fact of looking for actively pending approvals or the like like that. So just know, at face value by default, you’re pulling in historically whoever’s been set to approve a proof in Workfront.

So just as importantly, what is it now? I want to start off with noting that a proof approval report is not a proof report. Calling it this creates the misconception we are reporting on a proof object. The closest thing to a proof report would be a document version report, filtered to show versions only associated with a proof. Just to kind of highlight and compare, calling a proof approval report a proof report would be like calling a task report a project report. There’s an obvious difference, and we want to make sure even jumping in and creating the default report so we understand the object type we’re reporting on. Because the report shows a historical record of what’s set to approve a proof by default, it’s not expected to pull in actively pending approvals, which we touched on in the last slide. Filters must be put in place to gear it towards a need like this. So there’s going to need to be familiarity with what it’s pulling by default and then what fields are available so we can set the report up to work best for your situation. And so we’ll be covering some of that in upcoming slides.

The one thing we need to know, and this isn’t just for proof approval reports. Familiarity with the API tables available to us with the associated objects are going to expand your ability to take reports to the next level. That coupled with text mode, you’re going to be getting a lot more out of your reports.

Knowing that the fields are available and where the proof approval object exists when we’re speaking in regards to the API is going to help us understand and highlight what we can and can’t do and what limitations we’re facing when we’re working with this report. For comparison, there are nine supported fields on the proof approval object compared to 100 plus on a task object. Referenceable objects at the proof approval level are also limited. We have to go through either the approver, which is a user object, or document version table to access other tables and data points. So we’ll get into some of the more advanced text mode, then it’ll highlight why you need to have that understanding with the API in order to reference objects you can’t typically get outside of the UI or build complicated exists filters and the like like that.

So how to work with the limitations. The fact that we’re already starting with an object that has little data points in comparison to other objects, as well as fewer paths to get to other tables within the environment, that’s where the advanced methodology is going to come in to help you take the report type further outside of what you can with the UI. Getting your hands dirty with the text mode is going to allow you to bypass some limitations imposed by the UI. This is not a solve all. It’s not magic, but it still opens up a lot on how the report can be used. Whether you’re looking at pulling in data from objects not available through the UI by building your own path to it, creating value expressions to get a little more fancy with your end output beyond just referencing a field, or building exists to reference data too far away from the object for a normal filter, there are a lot of options available. So you can see in the first example, the table jump example, typically you’re really only getting in the UI an object away normally when you’re pulling in references as a column. So in this circumstance, we should be able to hit data on the document version table in the UI for the proof approval report. In this circumstance, if we’re wanting to jump up higher than that, we have to build a path using table jumps, which is highlighted here with a value field line, where we start obviously at the proof approval object, and then we’re dictating we’re jumping to document version, then to the document object, then the task, and then we reference the name. So ultimately, that example would return a task name in your proof approval report, even though that’s not available via the UI. With the exists example, we bridge the gap with linking objects to filter by project status. You can filter by a variety of other things, just like you could in a typical filter. It’s very much about understanding how the exists filters work, and identifying objects to bridge the gap between where we’re starting and where we ultimately need to end up. And this comes into play due to the fact that filters do have a two jump limit. So typically, you can only really reference data in a filter via the UI that’s one table jump away, because then we’re jumping to that table and then referencing filter. We’ll go a little bit more over how the exists filter works in later slides as well as the demo. But just note that the one there is one we would be calling to the project status. On the note of text mode, I do want to highlight that those of us in support do love to help when possible. But when it comes to building out custom text mode solutions, this does typically fall outside the normal scope of support and would need to be handled by professional services. Just keep that in mind when engaging support with asks surrounding building text mode. We’re always happy to help troubleshoot in any capacity that we can, but just want to set the expectation that you probably won’t be able to reach out and ask for a custom exists filter to be built out for you.

Moving on. So jumping into some of the common use after we’ve dictated what a proof approval report is and what it isn’t, we’ll touch on two of the common usages before moving on to common limitations we run into and known issues that might pop up. So the first common use case is one most all of you are likely familiar with. Is the reporting on approvals currently pending a decision? Set up with the callout below, you can create a report that actively shows approvals pending by user. Depending on your setup, you can focus this per individual dynamically using wildcards. Or another approach can even focus it on specific home teams, home groups. We’ll actually cover more of the setup specifically near the end of the presentation in the demo. So just to help get that visualization of walking through some of the UI elements as well as even walking through some of the text that we’ve gone over. So by implementing group by approver name, filter by awaiting decision equals true. I do want to highlight that filter actually takes into account multiple criteria that we’ll also cover later. And then filter by approver home team ID or specific users. Or alternatively, we can create the dynamic version for user ID or other wildcards that will return objects relevant to the user viewing the report.

The second most common usage we see of a proof of proof report is letting you see how many approvals are occurring over a given time. Whether that’s ones with decisions made or just approvals being created and sent out for your end users, it’s ultimately up to you. But just seeing that historical record of how many approvals we’re running through over x amount of time. So again, using the examples below, you can create a report that shows the amount of proof approvals that have taken place over a set amount of time. There are a lot of variables here that can be changed to focus on certain time frames. And this can easily be charted by it, just based on the groupings you’d be setting up. So obviously, we’d want to create the proof of report. Group by proof approval decision date. You could do by week, month, quarter, whatever is going to be relevant to how you want to see that data laid out. And then subgroup by approver name. That’s ultimately going to give you a count of the approver in that time span that you’re setting in the initial grouping. And then see that for all users roll up into that top grouping for the time span. We can still focus this with filters, obviously, by filtering on decision date or proof creation date over x time as well. And if you’re not keen on using static dates, that’s where we can use the date-based wildcards to set up filters that are on a rolling basis. So for example, there are some built-in ones when you’re filtering by a date field that will pop up. You can select those, and it actually gives you a good demonstration of how some of those wildcards would work, which if you go and read the documentation, you can further modify with specifics by modifying the modifiers at the end. So this one right here would be for this year, and that’s just specifying from today, the beginning of this year, through today, and the end of this year.

All right. So now, jumping over to some of the common pitfalls and limitations and known issues, we’ll be touching on things such as the historical record by default, which we’ve talked at some level, but just wanting to highlight how that comes in as a limitation and how understanding the fields that are available to filter bind stuff come into play. Filters only allow us two jumps. We reference that. That’s a report limitation. That’s not necessarily a proof of approval report specific limitation. And that’s where we’ll touch on the exists and go over exactly how it’s working in that circumstance. And then we can talk about the filtering issue or data inaccuracy, which comes up sometimes due to data getting out of sync when we’re pushing the updates from the proof tool back to Workfront to update that proof approval object.

OK. So historical record by default. As noted before, the proof approval report is a historical record of Workfront users set to approve a proof. Understanding some of the fields available will allow us to build reports relevant to a user or users’ current pending approvals. The awaiting decision field takes into account multiple factors, only returning true when all of these are met. This is one of the most useful filters to put into place due to the nature of most people wanting a report that shows current pending approvals. So the awaiting decision field, and this can be found in the documentation, there’s an article, I believe, titled Using Proof Approval Reports. So note that. This displays as true to signal a decision has not been made on the latest version when the following are true. The proof has not been archived. The stage the approver is on is active. And the proof is pending approval. So taking into account all of those factors, even just setting up that one filter is already gearing you fairly close to just getting relevant pending proof approvals for your users.

You can then couple this, of course, with specifying the approvers to set it specific for certain individual or certain members. You could do it to teams, so on and so forth, just like we touched on in the previous slide. OK. This is probably the one that most people would be excited about. The filter is only allowing two jumps. So whether it be the UI or text mode, there is a hard limit to two jumps in a normal filter. For example, this means the furthest we can typically reach with the filters would be the approver or user table or the document version table and those fields that exist on those data tables. This can be worked around by understanding this filter’s performance. This can be worked around by understanding this filters, allowing us to bridge the gap to farther off data tables that would typically fall outside that two jump limit. This example is looking for proofs ultimately on a project that are in a current status. The first line is the object we use to bridge the gap to the data at the project level. So in this circumstance, we’re saying the document table will be our bridge to ultimately getting to the project table from a proof approval report. The second line checks the field that we specify at the linking object level against the field found at the proof approval object level. So here, we’re saying at the proof approval level, we’re taking the document version ID and comparing it to the current version ID found at the document level. If those match, we have a successful bridge there. And then that leaves it to the last two lines you’ll typically see in this circumstance, which act much like you would see if you ever created a filter and then switched to text mode. We’re just specifying from the document level, since we’ve created that bridge, we want to jump to the project and reference its status. And here, we’re looking for a current status. The bottom line is the modifier, which is in, which equates to equal. So we’re saying we want to return essentially any proof approvals on the document where we can see that its project status is currently set to current. So again, there’s a lot of uses for Exist filters that can be used even outside proof approval reports. Taking examples like this and breaking them apart and understanding how they’re working are going to help you understand and trying to build some out yourself in the future possibly. So just keep in mind that all of this is pretty relevant to what can be used in other reports. OK, so the most common issue we’re going to see with the proof approval report stems from when data gets out of sync, essentially. So data on the proof approval objects has been known to get out of sync when the approval object is meant to be updated. Verifying that the erroneous approval object matches what we see in the proof workflow and meets or doesn’t meet all filter criteria allows you to reach out confidently to support that there is an issue rather than a misunderstanding. So to help verify as we’re reaching out, if you’re seeing these discrepancies, whether that’s coming up with approvals returning that we don’t expect or approvals we want to return but aren’t, or even if we’re seeing what seems to be inaccurate information, such as a decision pulling into a column, we can take some steps just to verify that there actually is an issue, one of them being pulling the fields that you’re filtering by as a column when possible. This helps highlight if the proof approval meets your criteria or not rather than bouncing back and forth between the approval itself and trying to glean from that window, you can pull in the columns that you’re filtering by and just see if, yes, in fact, we would expect this to return in this circumstance.

We can verify that the data in the column matches when reviewing the workflow or approvals. So in the circumstance where the data is actually out of sync, it will pull into the column most likely being inaccurate from that comparison on the object itself as well. That’s when we’d have to take it that next step and start to verify directly on the object.

And then the last thing is understanding what the fields do. So just like we went over with the awaiting decision field that takes into account multiple criteria, there’s other fields that we need to have an understanding of what’s expected to know if it’s by design or we have an issue. Another example of this would be the proof deadline field. This actually displays the deadline of the proof, but every stage must have the deadline assigned in order for this field to populate. The field displays the deadline for the most recently active stage. So we do see questions around whether it’s that field or the awaiting decision field. So helping understand the expectation behind the field is gonna let you more confidently know if there’s an issue or not. And of course, ultimately, if it boils down to it and you think you’ve taken all avenues in troubleshooting an issue, we’re always here. Support is always happy to help, whether that’s troubleshooting an issue or helping you guide to the correct resources needed in any given situation. So as much as we want you to be absolutely enabled in success, you’ve always got us to lean on if needed.

All right. So this is when we’re gonna switch over to the demo.

Matt, did you have anything that you wanted to know? Yeah, thank you, Chance. Great job so far. If the demo does not, or the live screen share does not pop up, there is a red box at the far bottom right that will open the media player and will share the slides. So Chance, if you wanna share your screen and I will give you the go ahead when I can see it. Okay, there it is. So again, there’s a red box at the bottom right, media player, and that should pop up in the live demo for you. And you can change the screen size for your viewing.

Back to you, Chance. Thank you. All right, so there is a slight delay between what I do on screen. So I’ll try to be mindful of that. And I apologize if I go a little too quick and we lose some of the actions, but obviously at face value, you need to create the proof approval report that’s found in your main menu, go to reports.

And then you can find it in your report types and just create that proof approval report. So just as we spoke about, ultimately we want this to be my approvals.

Uh oh, there we go.

So at face value, I’m gonna return a historical record of all the proofs that have been created that this user can see, right? Just like we can anywhere else in the instance. We’re gonna be returning those that are pending approvals, those that have been approved, those for other individuals. You can see that we have some for the proof approval user. We have some for Alex Beach. We have some for Darth Rufio. That is the base level of the proof approval report, that historical record of has this person been set to approve the proof. So walking through building this out a bit more. First, let’s add a column that’s going to pull in the related project’s status.

So again, using some of that text mode, the table jumping that we talked about earlier. I have my display name set to dictate that the column’s gonna be called project status. Text mode equals true. We have the value field line, which is specifying again, we start at the proof approval level, and then we’re jumping to document version, document, project, and then status. And then our value format dictates how it’s going to ultimately yield and display on the screen. HTML is the most common method for most text mode. So that’s typically our default, unless you’re getting into things such as formats with numbers and you’re looking for certain decimal places or the like like that. So with that in place, that highlights things we can do table jump wise, and it’s also gonna allow us to see how the exist filter successfully works ultimately towards the end of the demo. So with that, one thing I want to add is the approver name as a grouping, and just highlight how much even just taking a simple grouping is going to clean up what it looks like ultimately, right? So last time we just had a list of all these various approvals within the system. Now that we’ve grouped by it, we can see that we have four currently for the proof approval user, one for Alex Beach and one for Garth Rufio, just at a glance. Note that we are successfully pulling in the project status of current, which is the CUR is the code for the status.

And we’ll jump back in and continue to just work with the report in gearing it towards different ways we can make it relevant for you, your users or your organization. So as noted earlier, the most common filter we’re likely going to see is the awaiting decision equals true. So again, this is taking into account multiple factors in regards to if the proof is archived, if it’s actually currently pending an approval, and if the stage the approval is on is active. So that does take into account quite a bit of what we typically expect to see on the report. And you can see that the original approval that had been approved as the decision has now dropped off because it’s no longer pending that decision, right? So it’s being caught by our awaiting decision equals true due to the factors that it takes into account.

Now, let’s say we want to make this filter more relevant to specific individuals. Maybe we just want this to be relevant to our proof approval user and maybe Alex Beach.

So again, we’re just filtering it further, returning those that we need in that circumstance.

So now we have Alex and we have the proof approval user, thus having dropped off the Darth Rufio user. So maybe this is just us taking it down a bit further for the users that are gonna be using the report.

The other approach, if we want to get into users, is we can make this a more dynamic report where we utilize our wildcard. So what this would do is it’s gonna come in and it’s basically gonna check the user who is viewing the report and return the results where their ID equates to the approval ID. So it creates a dynamic report that could be used across multiple people, but only return relevant information to them. There are other wildcards that can be used against teams and groups and the like. So this is just one example. Again, get out there, read the documentation in regards to wildcards and see what kind of things you can throw together. But now that we have that in place, we see that we’re only returning the approvals set up for the proof approval user. One thing I do want to note when you’re using the wildcards specifically is that if you are going in and setting a run this report with the access rights of as a user, that’s going to take into account and apply the user we put here for the wildcard. So you do lose that dynamic ability of the report if you’re running the report as somebody else. Just keep that in mind.

The last thing is now, I want us just to highlight, we have three approvals returning right now. It’s fairly relevant to what the user needs to be aware of at this point in time, except for the fact that we have an approval pulling in from a project that’s not an occurrence step.

This could be relevant to whether it is implying you’re probably more common going to see it for projects that have been closed or the like like that, which ultimately if the project’s closed, those proof approvals may no longer be relevant. But we’re not going to see that cascade down. This is where the Exist filter is going to come into play. And you do have to switch to text mode in order to apply these. So the Exists call out here is what’s tying all these lines together, basically dictating that they’re used in conjunction with each other. Again, we’re specifying the object code that we’re using to bridge the gap as the document. And we’re comparing the document version ID found at the proof approval level to the current version ID found at the document level. If those match, we successfully bridge that gap. From there, we’re just specifying from the document level, we want to reference the project’s status and check to see if it equates to current using the modifier. So now with that in place, we see that the approval that was tied to the project in the plan status has now dropped off. So in theory, you’re just broadening how concise you can get your report to be by getting into those advanced text mode methods whether that be pulling in the information so things can be seen at a glance or filtering information so you’re only returning a very specific data set.

I guess with that being said, that’s the end of the presentation. I hope everybody was able to take something away from it even if it is just reinforcement for some of our more advanced users.

We do have time for more questions so I’ll likely be seeing if I can jump in and help with some of those questions.

Yeah, Chance, it looks like there are maybe one or two.

We have our team has been absolutely rock stars answering everyone’s questions. So thank you to the team behind the scenes. But if there’s anything Chance that you can see in the Q&A that you would want to answer real time, feel free.

And if anyone else doesn’t have any more questions, thank you for joining and feel free to drop. As I mentioned earlier, there will be a recording of this. It is actually the exact same URL that you used to join this session and it will be available for recording about 24 hours from now.

Cool.

Nicole, with the widgets found in home, and I don’t think your question has been answered yet, with the widgets found in home, I believe, I don’t believe, I’m not as familiar with the widget and if that’s set up as a list or if it’s one of the more customized ones. If there is the ability to create filters and apply it to that list, I’m assuming you probably could utilize the same exists method and return the end results. But if the widget is very much geared towards a more custom UI outside of what we do, typically seeing the lists, you’re probably not going to be able to get in and specify project status.

Alan, could you report on proof approval, durations for closed proof approvals to get an idea of how long they’re taking approval from start to finish? I think there’s a possibility because I believe there is a data set. You’re asking if you can see the duration of the time it’s created to basically the decisions made. I think you could on a per decision basis, because I believe there is, I believe there’s a date field that captures when the decision is made. And you could absolutely do a difference between that and I wanna say either the proof creation or the like, which would at least get you in the direction of likely seeing a difference or that date difference from when it’s created to when it’s approved essentially.

Let’s see.

Looks like, so Eileen Taylor, newbie to text mode, how do I show the project name in a column? I think we actually went over one of those as example, or that might have actually been just us pulling in project status, nevermind. So the example where we do the value field equals document version, then document, then project, instead of ending that with status, if you end that with name, that would ultimately pull in the name. So a lot of the examples we were using were just two specific data points on those tables. Those can absolutely be applied and you could switch out the field on that object we jumped to and ultimately return that. It’s just a matter of, again, probably getting in and learning to use the API Explorer to one, identify the path and to build out the syntax to successfully return the value.

Tim, if you can jump to project, see project status, can you see issue status? You should absolutely be able to see issue status. The only question at that point would be, is every proof or in the instance with the proof approval going to be on an issue? You could probably still gear it towards only returning those on an issue using methods that we found here. But as long as it’s on an issue, you should absolutely be able to return the issue status as well.

Let’s see.

Mara Felton, how do we set up a report to manage the new proof limit? So I have a report by users by quantity of approvals per month, so we can manage overages or license update. I would expect this should be an out of the box report where it can be provided. So that might be gearing more towards, I don’t know if you’re gonna necessarily glean that from a proof approval report because we’re reporting on a specific object created when someone is set to approve. This sounds more like a usage report in both license type and how often they’re approving, if I’m understanding right.

I can’t say for certain there’s gonna be anything that’s gonna meet that need right now. But that’s without assessing if a user report could be used to at least assess the license type.

Just not knowing if that’s going to take into account their amount of approvals. It may be something where it needs to be set up in conjunction with the proof approval report to get a holistic view. But at least at face value, I don’t think there’s something necessarily by default that’s going to show that as we switch over to the new license type.

Okay.

Rachel Kirkpatrick, our proofs usually have seven to 10 approvers. Our reports for users show proofs waiting for their approval even after they’ve made decisions. It looks like that might have just been answered. Unless somebody, I’ll keep running with it. They’ve made decisions that others haven’t yet. How can we remove the proofs from their report after they’ve made decisions even if the others haven’t? That may ultimately dictate setting up a process. It’s hard to say without exactly looking at it, but that may dictate setting up a process. I believe there’s an option to only need one approval, but even in your circumstance, it sounds like you may still necessitate the need for multiple approvals before it moves on.

That sounds like a pretty specific use case. There may be methods that it could be achieved, and maybe that’s through a task dictating it when the correct approvals are done on it, and that task being moved to a closed status due to it being closed, and then filtering by the task status. I don’t know if we can necessarily return if we have the approvals we want without a system setting that would say, okay, no more approvals are needed. I am aware that there’s one that’s only one approval is needed or the like, but I don’t think that’s a one size fits all. So it may take a little bit more to get to that ultimate end goal there.

Troy, can you run a search for proofs with an approver but has reviewers? So you can absolutely return a proof approval object. Speaking in terms of a proof approval report, you can absolutely return an approval object if there’s reviewers on it, but that object is only going to be an example of the approver. If you’re looking for a more holistic view of reviewers and approvers, you’re probably gonna be better off trying to get that information through a document version report and then filtering it by proof ID. So we’re only returning document versions that have a proof associated with it. And then you likely can return, there’s a good chance you could return those in the workflow whether they’re reviewer or approver or both through collections, which is another advanced text mode thing. But I think there are possibilities that you can get and show reviewers, but that’s gonna be more easily and more readable at a document version level, I think.

Let’s see, answer a few more questions.

So Steven Stanton, when you mentioned only allowing two values to change, are you specifically referring to text mode line changes? So I think in terms of what you’re trying to say is the jumps, the table jumps, which is us specifying a path, whether that’s us returning it in a column or us returning it in a filter. In a column, there’s not necessarily a limitation there. You can jump as if you can build a path to the object, you can successfully return it. I have yet to see a hard limit on that, those jumps, but when we get into when we’re creating the filters, you can only jump twice. And so that dictates we’re jumping from the proof approval object to either the user or which is the approver or the document version, and then referencing a field on that table.

From what I understand and why that limitation is in place is to ensure that the queries that are being generated are as efficient as possible. But even then, with those limits in place, we have come across queries created from filters that cause slow report load times and the like. So that limits there, the exist filter is what helps us bypass that. And for some reason, I think it has to do with the way it generates the query. A lot of the times we’ll see filters that are having issues loading work more efficiently if we build exist filters in those circumstances. So it’s an interesting thing to approach.

Kristy Kibler, I think I just answered that one.

I don’t necessarily think there’s a jump limit when we’re returning values in a column. I have yet to personally see one and I’m not aware of one that was called out. The only jumps I’m aware of are the filters and there is a limit when it comes to trying to solve it. I think it’s sort by that information. And I think that one actually is three. So maybe that may be what you were calling, but.

Muhammad, why document version report is not having export option from the details tab to download an Excel format. So a little bit off of the proof approval object report, but still pretty relevant. The document version and the document report don’t have the export list capabilities. And that has actually come up a few times in the past, but it just currently doesn’t. Instead they work in the capacity of exporting the documents.

So the function, why that decision is made, I’m not quite sure. But from a functionality perspective, that’s how they work currently. Troy Tran, is there a way we can email you directly with a case? Maybe, I’ll think about it.

Madeline DeStefney, it’s been a while. Pro tip for report users. Awesome, Madeline coming in clutch in the question. Troy, there is no approver assigned.

I’m not sure what that’s in relation to. I might be breaking off from when, oh, I think that’s a followup to your question. So again, I think that’s a followup to you wanting to report on reviewers. Currently the proof approval report only will return based on proof approvals.

If we’re looking for a more holistic view of reviewers, document version report is likely gonna be your best bet. Kristy Kibler, built-in jumps, not text mode jumps.

We might see some tables built-in jump a little bit further. That just depends on if development has pre-built those out to reach that far, basically. The most common is going to be a table jump away, which ultimately when you view as text mode is gonna look like two jumps.

But there are circumstances where we do jump further based on what dev has put in place.

I think Louise heard SOG, so to be clear, there is no direct way to tie due dates to the status of pending to show how past due the status is.

I think with how many limited fields are on the proof approval object, I don’t have it currently pulled up right now.

I know there’s the proof deadline, but again, there’s nuances behind what necessitates that populating. So as long as you’re having that populate, you might be able to get information gleaned from how far past they are, but it’s probably gonna need to be a pretty consistent specific setup to ensure the data populates and then a custom setup to likely show us passing that, whether we do that through something like conditional formatting or a custom value expression in text mode in a column.

All right, I know.

So Tammy, these support case entries count against those support case limits, yes? I’m not sure I understand the question fully in regards to support case count.

All right, I think that looks like the question’s answered. Questions answered.

Great, thank you so much. Chance, great presentation. I hope everyone that’s still on the line got some value out of this. We’re going to close this webinar session. If you do have additional questions, please do reach out via support case and the team is more than happy to answer them. We’re happy to help out. Again, as I mentioned, this recording, along with the PowerPoint slide deck, will be sent out to all of you about the same time tomorrow. So take a look for that. It’s totally free to share with anyone else who may have not registered or with anyone on your teams. And I thank all of you for joining and I hope everyone has a great rest of the day. Again, thanks to Chance, thanks to Nathan Johnson, Kiva on our Q&A team. Thanks to everybody that has helped out here and we will hopefully have another session soon.

Thanks everyone. Thanks everyone.

Thank you.

Thank you.