Updated June 2026. Rewritten for Lightning Experience with the two gotchas that actually stop the field appearing: the action layout and the global publisher layout.

Salesforce global actions are the quick buttons in the header that let a user log a call or create an event from anywhere, without opening a record first. The most common one is the New Event action, and sooner or later someone asks to capture an extra detail on it, a meeting type, a region, a follow-up flag. Adding that field is a five-minute job once you know where the two relevant screens are, and a frustrating afternoon if you do not.

We configure Salesforce for clients at Osher Digital, a Brisbane AI and automation consultancy, and the Event global action comes up often because it sits in everyone’s header all day. This guide walks the exact steps in Lightning Experience, then covers the parts that catch people out: where the custom field has to live first, why a saved field still does not show, and how field-level security can quietly hide it from half the team.

If you are weighing up field permissions while you are in here, our companion piece on what controls field visibility in Salesforce explains why a field can be on the layout and still invisible to some users.

What Salesforce Global Actions Are

A global action in Salesforce is an action that is not tied to a particular record. It lives in the global header, the plus menu in Lightning, so a user can create a record from any page. New Event, New Task, Log a Call, and New Contact are the standard ones, and you can build your own. Because they are not attached to a parent record, they are configured centrally rather than on an individual object’s page layout.

The New Event global action creates a record on the Event object, which is part of Salesforce Activities. That detail matters more than it looks, and it is the source of the first gotcha further down. For now, the thing to hold onto is that global actions in Salesforce have their own layout, called the action layout, which is separate from any page layout you have edited before.

People reach for these because they cut clicks. A salesperson finishing a call can log the next meeting from the header in seconds rather than navigating to a contact first. That speed is the entire point, so keeping the action layout tight matters as much as adding the right field.

Before You Start: Make Sure the Field Exists

You can only drag a field onto the action layout if that field already exists on the object. For the New Event action that means the field has to exist on the Event object first. If you want a custom field, create it before you touch the action layout.

Here is the first real trap. Event and Task are both Activities in Salesforce, and they share their custom fields. When you create a custom field under Setup on the Activity object, it appears on both Events and Tasks. There is no Event-only custom field. If you add a “Meeting Outcome” picklist expecting it on events alone, it will turn up on tasks as well, and you cannot split them. Plenty of admins discover this after the field is live, so decide up front whether that is acceptable or whether a different design fits better.

To create the field: Setup, Object Manager, open Activity (not Event, the custom field option sits under Activity), then Fields and Relationships, then New. Pick the type, name it, set field-level security, and add it to the relevant page layouts. With the field in place, you are ready to put it on the action.

How to Add a Field to the Event Global Action

This is the core procedure, and it sits behind a pile of related searches: how to add global action in salesforce, global action salesforce, global actions salesforce, and how to add a field to a global action in Salesforce. They all land on the same screen. We use the New Event action as the example here, and the same steps work for Log a Call or any other global action.

Go to Setup and enter “Global Actions” in Quick Find, then click Global Actions.
Find the New Event action in the list. The Object column reads Event and the Standard Type is typically Create a Record.
Click Layout next to it. This opens the action layout editor, which is the canvas for that action only.
From the palette at the top, drag your field onto the layout where you want it to appear.
Set it required or read-only on this action if you need to, using the wrench icon on the field.
Click Save.

That saves the field onto the action layout. If the New Event action is already in your users’ headers, the field will show the next time they open it. Most of the time you are done here. When you are not, it is almost always one of the two issues in the next section.

If you would rather have this configured and tested for you, or you are setting up actions across several teams at once, book a call and we will sort it.

Why Your Field Still Does Not Show

Two things account for almost every “I added it and it is not there” report we see.

The action is not on the global publisher layout. Editing the action layout decides what is inside the action. The global publisher layout decides whether the action appears in the header at all. If the New Event action is not on the publisher layout assigned to that user, no amount of layout editing will surface it. Go to Setup, search Publisher Layouts, edit the right one, and make sure New Event is in the Salesforce Mobile and Lightning Experience Actions section. This is the single most common reason a freshly edited action seems to vanish.

Field-level security is hiding the field. The field can be on the action layout and still be invisible to a user whose profile or permission sets do not grant it. The action layout governs placement, field-level security governs access, and access wins. If only some users see the new field, this is almost certainly why. Check field-level security for the field across the relevant profiles and permission sets, which is the same access model we cover in the field visibility article linked above.

Work those two first. We have watched people rebuild a perfectly good action three times before checking the publisher layout, which is a quiet afternoon nobody gets back.

Predefined Values and Required Fields

Once the field is on the action, two settings make it genuinely useful rather than just present. The first is predefined field values. On the global action itself you can set a default value so, for example, every event created from this action starts with Type set to “Sales Meeting.” That turns a field people skip into data you can actually report on.

The second is marking the field required on the action. Be careful here. Required on the action layout forces a value at creation, which is great for data quality and irritating if the person genuinely does not have the answer yet. We tend to make a field required only when the business truly cannot use the record without it, and lean on predefined values the rest of the time.

A small but real warning: validation rules on the Activity object fire when the event is saved from the global action too. If you have a validation rule that depends on a field you did not put on the action, users will hit an error they cannot resolve from the quick create. Either add the field to the action or scope the validation rule so it does not trip on global-action creates.

Global Actions vs Object-Specific Actions

It is worth knowing when the Event global action is the wrong tool. A global action creates a record with no parent context, so an event made this way is not automatically related to the account or contact a user happens to be looking at. If your team mostly logs meetings against a specific record, an object-specific action on Account or Contact captures that relationship automatically and is the better fit.

Use the global action when speed from anywhere matters more than the relationship, for example a field rep logging the next meeting between calls. Use an object-specific action when the event should hang off the record in view. Many orgs run both, and that is fine, as long as you are deliberate about which one each team is trained to use. Adding a field follows the same steps in either case, just on a different action.

This is the kind of small design call that quietly shapes data quality. We see plenty of orgs where half the events have no related record because everyone uses the global action out of habit. If that sounds familiar, it is usually worth a quick review rather than a rebuild.

Classic vs Lightning, and Mobile

The steps above are for Lightning Experience, which is where almost every org now lives. In Salesforce Classic the action layout editor exists but the publisher layout behaves slightly differently, and the global header is laid out another way. If you are still on Classic for some users, test the action in their actual interface rather than assuming parity.

Mobile is the other thing to check. The Salesforce mobile app respects the same action layout, so a field you add appears there as well, but screen space is tight. A New Event action with twelve fields is fine on a laptop and miserable on a phone. If your reps create events on mobile, keep the action lean and put the rarely used fields on the full record page instead.

The general rule we give clients: the global action should hold the few fields needed at creation, not the whole record. Everything else belongs on the record page, where there is room and where field-level security and record types already do their job.

A Worked Example: Adding a Meeting Type Field

To make the steps concrete, here is a job we do for sales teams often: add a “Meeting Type” picklist to the New Event action so reps tag each event as a discovery, demo, or check-in straight from the header. It is a small change with an outsized payoff, because suddenly the activity report can tell you what kind of meetings are actually happening.

We start by creating the picklist on the Activity object, knowing it will appear on tasks as well as events. Then we add it to the action layout, set a sensible predefined value so the most common option is preselected, and confirm the New Event action is on the right global publisher layout. Last, we check field-level security so every sales profile can see and edit it. That is the whole sequence, and it maps one-to-one onto the order below.

Create the “Meeting Type” picklist on the Activity object with the values the team uses.
Open Global Actions, click Layout on New Event, and drag the field into place.
Set a predefined value on the action so “Discovery” is preselected.
Confirm New Event is on the global publisher layout for the sales teams.
Verify field-level security grants the field to every relevant profile and permission set.

Build it in a sandbox first if you can, especially when a validation rule or automation touches the Activity object. We have seen a “harmless” required-field change on the Event action block every quick-create across an org because an old validation rule did not expect it. Five minutes in a sandbox would have caught it. That is the one habit worth keeping even for a change this small.

Frequently Asked Questions

How do I add a field to a global action in Salesforce?

Go to Setup, open Global Actions, click Layout next to the action (for example New Event), then drag the field from the palette onto the action layout and Save. The field must already exist on the underlying object first. For the New Event action that object is Event, which sits under Activities.

Where are global actions in Salesforce setup?

In Setup, type “Global Actions” into Quick Find and select Global Actions. That page lists every global action with its object and type. To control which actions appear in the header, search Publisher Layouts instead, which is a separate screen.

Why is my new field not showing on the Event action?

Usually one of two reasons. Either the New Event action is not on the global publisher layout assigned to that user, so the action itself is missing from the header, or field-level security on the user’s profile or permission sets does not grant the field. Check the publisher layout first, then field-level security.

Can I add a custom field to only events and not tasks?

Not with a custom field. Events and Tasks share custom fields because both are Activities, so a custom Activity field appears on both. You can place it on only the Event action layout, but the field still exists on tasks. If you need true separation, rethink the design before creating the field.

How do I set a default value on the Event global action?

Open the global action in Setup and use Predefined Field Values to set a default, such as Type equal to “Sales Meeting.” Every record created from that action starts with the value, which lifts data quality without making users type it each time.

Do validation rules apply when creating an event from a global action?

Yes. Validation rules on the Activity object fire on save from the global action. If a rule depends on a field that is not on the action layout, users hit an error they cannot fix from the quick create. Add the field to the action or scope the rule to avoid global-action creates.

How much does Salesforce customisation like this cost in Australia?

Adding a field to an action is a quick admin task, usually well under an hour. Australian Salesforce admin support generally runs $150 to $250 AUD per hour, and a small package of layout and action changes is often quoted as a fixed $500 to $1,500 AUD. The cost only climbs when validation, automation, or reporting changes ride along with it.

Does the field appear in the Salesforce mobile app?

Yes. The mobile app uses the same action layout, so a field added to the New Event action shows on mobile too. Keep the action short, because a long action is awkward on a phone. Put rarely used fields on the full record page rather than the action.

Global actions are small, but they sit in front of your whole team every day, so getting the fields and defaults right pays off quickly. If you want your Salesforce actions, layouts, and automation tidied up so they actually match how your team works, get in touch and we will help.

Salesforce Global Actions: Add a Field to the Event Layout