Product ideas | Community
Skip to main content

Filter by idea status

10000+ Ideas

Expose Workload Balancer information via a proper API objectNew

DescriptionWorkload Balancer information is currently exposed via the ASSGN:workPerDate and TASK:workPerDate fields.  These fields truncate at 1,000 entries, with no ability to investigate further into those due to how the API's pagination works at the parent object level (ASSGN/TASK).  What is needed is the ability to pull the workPerDate information via a separate object that supports pagination (ideally via a cursor rather than an offset).Why is this feature important to youWe bring Workfront information into Snowflake and link it to data from other systems, such as Salesforce, NetSuite, Workday, etc.  Workload Balancer is an incredibly powerful tool that helps our project managers, and we need the per-resource/per-day assignment information in order to ensure our systems are synchronized properly for reporting purposes.  Without exposing this information via a proper API object, there is no way to ensure information is accurate and not truncated.How would you like the feature to workMake the workPerDate more of a collection of a proper object, with that collection associated with an ASSGN and TASK, perhaps called something like "WORKITEM" or "WRKITM".  An example of the object structure could be:IDobjCodecreationDate (date the object was first created)workDate (date the object references for the work to be done)lastUpdated (timestamp)lastUpdatedBy (user ID)parentObjCodeparentObjIDhoursSince these work items can change frequently, offset-based pagination ($$LIMIT/$$FIRST) really doesn't allow for pulling of all this information in a reasonable way.  As such, it would be best to use cursor-based pagination so that repeated API calls to pull a set of information doesn't cause "gaps" -- that is, the paginated API has a "transactional" nature to it.Current BehaviourSee the ASSGN:workPerDate and TASK:workPerDate fields.  The main issue is around pagination, with those fields each truncating at 1,000 entries max.

Add basic sanitization by removing Unicode control characters, whitespaces from Email Address fieldNew

Today, if a Marketo user is entering email addresses into their system, there is no sanitization of characters that may not be allowed by RFC 6530. While the majority of Unicode is technically valid for an email address, the standard itself notes:"The local parts of those addresses MAY be made up of any ASCII characters except the control characters that RFC 5321 prohibits, although some of them MUST be quoted as specified there."If we cross-reference this section of RFC 5321, you'll notice that it explicitly calls out that the specific characters noted are "control characters (US-ASCII 0-31 and 127; inclusive)". Likewise, any form of whitespace is explicitly excluded from the email spec: RFC 5321, Section 4.1.2 defines the syntax for mailbox, local-part, and domain, which excludes whitespace and RFC 5322, Section 3.2.3 details the allowed characters (atext) for atoms and dot-atoms, excluding whitespace. Recently, I was working with a client who had a record's email address formatted as "test@example.com " instead of "test@example.com", which lead to email delivery failures. However, there is no way to query whitespace characters (in this case, Narrow No-Break Space (U+202F)) in Marketo, so there is no way to find and correct this issue. In this case, it makes logical sense to strip all types of whitespace and control characters from the Email Address field. This prevents user error (which is common with email addresses in uploaded lists) and provides a better experience—while never violating any email standards. Could this please be implemented?