You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You will notice that the argument `DisableFeedTrackingHeader` can be included right into
64
-
the function without any documentation existing for it in the `sf_create` function.
65
-
This is because the dots (`...`) allow you to pass over a dozen different control
66
-
parameters and that documentation would be tedious to create and maintain over multiple
67
-
functions in the package. However, you will notice in the documentation entry for
68
-
the `control` argument there is a link to a function called `sf_control` which you
69
-
can use to directly to pass into `control` or simply to review its documentation of all the
70
-
possible control parameters and their defaults. This is where you can review the various
71
-
control options in more detail before trying to set them.
72
-
73
-
You may have also noticed that the argument <ahref="https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_header_disablefeedtracking.htm"rel="noopener noreferrer"target="_blank">DisableFeedTrackingHeader</a> was formatted
74
-
as a list with an element inside called `disableFeedTracking` set to `TRUE`. This may
75
-
seem redundant but there are two reasons for this. First, this is exactly how the
76
-
Salesforce APIs documents these options, which are typically referred to as "headers"
77
-
because they are passed as a named header of the HTTP request and then the header fields
78
-
and values are provided for that header. Second, some headers have multiple fields and values
79
-
so a list is the only way to provide multiple named fields and values under a single header entity.
73
+
You will notice that the argument `DisableFeedTrackingHeader` can be included
74
+
right into the function without any documentation existing for it in the
75
+
`sf_create` function. This is because the dots (`...`) allow you to pass over a
76
+
dozen different control parameters and that documentation would be tedious to
77
+
create and maintain over multiple functions in the package. However, you will
78
+
notice in the documentation entry for the `control` argument there is a link to
79
+
a function called `sf_control` which you can use to directly to pass into
80
+
`control` or simply to review its documentation of all the possible control
81
+
parameters and their defaults. This is where you can review the various control
82
+
options in more detail before trying to set them.
83
+
84
+
You may have also noticed that the argument <ahref="https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_header_disablefeedtracking.htm"rel="noopener noreferrer"target="_blank">DisableFeedTrackingHeader</a> was
85
+
formatted as a list with an element inside called `disableFeedTracking` set to
86
+
`TRUE`. This may seem redundant but there are two reasons for this. First, this
87
+
is exactly how the Salesforce APIs documents these options, which are typically
88
+
referred to as "headers" because they are passed as a named header of the HTTP
89
+
request and then the header fields and values are provided for that header.
90
+
Second, some headers have multiple fields and values so a list is the only way
91
+
to provide multiple named fields and values under a single header entity.
0 commit comments